perm filename MESS[X3,LSP] blob
sn#871211 filedate 1989-03-15 generic text, type T, neo UTF8
∂01-Mar-89 1109 X3J13-mailer Section 1.7
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:09:32 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA00298; Wed, 1 Mar 89 11:07:25 PST
Message-Id: <8903011907.AA00298@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA00298; Wed, 1 Mar 89 11:07:25 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:23
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.7
%%Language Extensions
[{\it This section is dependent upon the passage or failure of the following
issues: EXTENSIONS-POSITION, EXTRA-SYNTAX, EXTRA-OPTIONAL-KEYWORD-ARGUMENTS,
UNSPECIFIED-DATATYPTES, UNSOLICITED-MESSAGES, MACRO-AS-FUNCTION, and
EXTRA-RETURN-VALUES. When they have passed or failed, this section
will be altered.}]
A language extension is
any implementation-supplied {\word tool} that isn't explicitly defined
in this standard. This includes facilities added to {\word tools} defined
in this standard.
An implementation may have extensions,
provided they do not alter the behavior of conforming code and
provided they are not explicitly prohibited by this standard.
From Common Lisp's point of view, defining an extension
refers to a facility's initial definition.
Whether an implementation permits redefinition of an extension is between that
implementation and its users and beyond the scope of this standard to
specify.
If this standard says that ``the results are unspecified", and an
implementation specifies the results, this an extension in the
sense that if the correct behavior of a program depends on the results,
only implementations with the same extension will execute the program
correctly.
In places where the standard says that ``an implementation may be extended",
this implies that a conforming, but probably non-portable, program can
be written using the implementation's extension.
%Following will be included if the proposal that states this is passed.
%An implementation is required to have a way to disable its extensions, so
%that a programmer can be told when he is using a feature that might
%affect his program's portability.
The following list contains specific guidance to implentations
concerning certain types of extensions.
\beginlist
\itemitem{\bf Additional syntax}
An implementation
is not allowed to extend {\word macros} and {\word special forms} to take
additional syntax not specified in this standard.
\itemitem{\bf Extra optional or named arguments}
Unless explicitly allowed in this standard,
implementations are not allowed to include definitions
of {\word functions} with extra optional or named arguments
with system-dependent meanings.
When extra optional or named arguments are allowed by this
standard, they will be annotated as follows:
{\word functions} that may be
extended to take implementation-specific optional arguments are indicated
by {\tt &rest ignore} in their argument list.
{\word Functions} that may be extended
to take additional keyword parameters are indicated by {\tt &allow-other-keys}.
The goal is not to outlaw any extensions currently offered by
implementors, but to make the range of extensions to {\word functions}
defined in
this standard well documented in this standard. Implementations that want to
extend {\word functions} that aren't explicitly
allowed to be extended can instead
shadow them.
% or as follows, if this proposal passes.
%Alternate proposal: NOT-IN-STANDARD-PACKAGE
%
%Like NO-EXCEPT-AS-ALLOWED, except that an implementation may always
%provide additional named arguments to a function if the names are not in
%an implementation-specific package (the list of these currently includes
%the LISP, USER, and KEYWORD packages).
%
\itemitem{\bf Extra return values}
Unless it is explicitly allowed in this standard,
an implementation is
not allowed to return extra values from {\word functions}
defined by this standard.
\itemitem{\bf Function behavior on non-standard data types}
An implementation does not define the behavior of {\word functions}
on data types not explicitly permitted by this standard.
\itemitem{\bf Unsolicited messages}
Unsolicited messages, such as garbage collector notifications
and autoload heralds, if
they are produced by an implementation, should not be directed to
@var[standard-output] or @var[error-output]\rm.
If an implementation produces them, they
may be produced on a {\datatype stream}
that is not shared with any of the {\datatype streams}
that a user might redefine or redirect. This means that an
implementation is allowed to
direct such notifications to @var[terminal-io] since a user may not redirect
@var[terminal-io]\rm.
Messages such as progress reports from {\function load} and
{\function compile} are solicited,
and are not covered here.
\itemitem{\bf Implementation of macros and special forms}
Operators that are defined as {\word macros} or
{\word special forms} may be defined as {\word
functions}
instead if the semantics can be preserved.
%or as follows:
%Alternate Proposal: MACRO-AS-FUNCTION:STATUS-QUO
%
%The standard will remain silent on the issue of whether or not is
%is legal for an implementation to implemention "macros" and
%"special forms" as functions.
%or as follows:
%Alternate Proposal: MACRO-AS-FUNCTION:DISALLOW
%
%A conforming implementation does not define "macros" and "special forms"
%as functions.
\endlist
∂01-Mar-89 1111 X3J13-mailer Section 5.2
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:10:51 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA00392; Wed, 1 Mar 89 11:08:46 PST
Message-Id: <8903011908.AA00392@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA00392; Wed, 1 Mar 89 11:08:46 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:25
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 5.2
%% Input/Output
It is possible to perform I/O to any device physically connected to
the machine on which the @xlisp\ system is running.
Some implementations, however, may not support the interfaces
to all possible physical devices. Some external
data sources
are treated specially in @clisp. The following sections describe the file
system interface, binary and character I/O, and the {\function load}ing process.
\beginsubSection{Files}
%% 23.0.0 5
@clisp\ assumes that files are named, that given a name a
{\datatype stream} can be constructed that
connects to a file of that name, and that the
names can be fit into a {\datatype pathname}.
%% 23.0.0 6
%Facilities are provided for manipulating {\datatype pathnames},
%for creating
%{\datatype streams}
%connected to files, and for manipulating the file system
%through {\datatype pathnames} and {\datatype streams}.
%Left out.
%% 23.1.0 1
In general, different
file systems have different naming formats for files.
There are two ways to represent file names:
namestrings, which are {\datatype strings}
in the implementation-dependent form
customary for the file system, and {\datatype pathnames}, which are
{\word objects} that represent file names in an implementation-independent
way. {\word Functions}
are provided to convert between these two representations,
and all manipulations of files can be expressed in machine-independent
terms by using {\datatype pathnames}. See ``Pathname''.
%% 23.1.0 2
%In order to allow code to operate in a network environment
%that may have more than one kind of file system, the pathname facility
%allows a file name to specify which file system (called the
%host) is to be used.
%Left out.
%%% 23.1.1 11
%Parsing is the conversion of a namestring
%into a {\datatype pathname}. This operation is
%implementation-dependent, because the format of namestrings
%is implementation-dependent.
%
%Merging takes a {\datatype pathname} with missing components
%and supplies values for those components from a source of defaults.
%This operation is also implementation-dependent because the
%set of valid {\datatype pathnames} that may result from merging is
%implementation-dependent.
%% 23.2.0 1
The basic operations for opening a file are {\function open} and
{\function with-open-file}. The basic operation for closing a file
is {\function close}.
Rules concerning file I/O follow:
\beginlist
%% 22.2.1 2
\itemitem{\bf Eof-error-p}
{\arg Eof-error-p} in I/O {\word forms}
controls what happens if input is from a file (or any other
input source that has a definite end) and the end of the file is reached.
If {\arg eof-error-p} is true (the default), an error will be signalled
at end of file. If it is false, then no error is signalled, and instead
the {\word form} returns {\arg eof-value}.
%% 22.2.1 4
\itemitem{\bf Recursive-p}
If {\arg recursive-p} is
supplied and not @nil\rm, it specifies that
this {\word form}
call is not a {\word top level} call to {\function read} but an embedded call,
typically from the {\word function} for a macro character.
It is important to distinguish such recursive calls for three reasons.
%% 22.2.1 5
\beginlist
\itemitem{1.}
A {\word top level} call establishes the context within which the
{\tt \#n=} and {\tt \#n\#} syntax is scoped. Consider, for example,
the expression
@lisp
(cons '#3=(p q r) '(x y . #3#))
@endlisp
If the single quote macro character were defined in this way:
@lisp
(set-macro-character #@bsl\ '
#'(lambda (stream char)
(declare (ignore char))
(list 'quote (read stream))))
@endlisp
then the expression could not be read properly, because there would be no way
to know when {\function read} is called recursively by the first
occurrence of @f['] that the label @f[\#3=] would be referred to
later in the containing expression.
There would be no way to know because {\function read}
could not determine that it was called by a macro character function
rather than from {\word top level}. The correct way to define the single quote
macro character uses {\arg recursive-p}:
@lisp
(set-macro-character #@bsl\ '
#'(lambda (stream char)
(declare (ignore char))
(list 'quote (read stream t nil t))))
@endlisp
%% 22.2.1 6
\itemitem{2.}
A recursive call does not alter whether the reading process
is to preserve whitespace or not (as determined by whether the
{\word top level} call was to {\function read} or {\function
read-preserving-whitespace}).
Suppose again that single-quote had the first, incorrect, macro character
definition shown above. Then a call to {\function read-preserving-whitespace}
that read the expression @f['foo ] would fail to preserve the space
character following the symbol @f[foo] because the single-quote
macro character function calls {\function read},
not {\function read-preserving-whitespace},
to read the following expression (in this case @f[foo]\rm).
The correct definition, which passes the value @true\ for {\arg recursive-p}
to {\function read}, allows the {\word top level} call to determine
whether whitespace is preserved.
%% 22.2.1 8
\itemitem{3.}
When end-of-file is encountered and the {\arg eof-error-p} argument
is not @nil\rm, the kind of error that is signalled may depend on the value
of {\arg recursive-p}. If {\arg recursive-p}
is not @nil\rm, then the end-of-file
is deemed to have occurred within the middle of a printed representation;
if {\arg recursive-p} is @nil\rm, then the end-of-file may be deemed to have
occurred between {\word objects} rather than within the middle of one.
\endlist
\endlist
\endsubSection%{Files}
\beginsubSection{Character and Binary Input/Output}
Figure {\chapno--\the\capno} lists reader and printer control variables.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
@var[read-base] & @var[read-suppress] & @var[print-escape] \cr
@var[print-pretty] & @var[print-circle] & @var[print-base] \cr
@var[print-radix] & @var[print-case] & @var[print-gensym] \cr
@var[print-level] & @var[print-length] & @var[print-array] \cr
@var[read-default-float-format] & & \cr
\noalign{\vskip -9pt} }}
\caption{Reader and printer control variables}
\endfig
Figure {\chapno--\the\capno} lists character and binary input
stream {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt read }&{\tt read-preserving-whitespace }&{\tt read-delimited-list }\cr
{\tt read-line }&{\tt read-char }&{\tt unread-char }\cr
{\tt peek-char }&{\tt listen }&{\tt read-char-no-hang }\cr
{\tt clear-input }&{\tt read-from-string }&{\tt parse-integer }\cr
{\tt read-byte }&{\tt }&{\tt }\cr
\noalign{\vskip -9pt} }}
\caption{Character and binary input tools}
\endfig
Figure {\chapno--\the\capno} lists character and binary output
stream {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt write }&{\tt prin1 }&{\tt print }\cr
{\tt pprint }&{\tt princ }&{\tt write-to-string }\cr
{\tt prin1-to-string }&{\tt princ-to-string }&{\tt write-char }\cr
{\tt write-string }&{\tt write-line }&{\tt terpri }\cr
{\tt fresh-line }&{\tt finish-output }&{\tt force-output }\cr
{\tt clear-output }&{\tt write-byte }&{\tt format }\cr
\noalign{\vskip -9pt} }}
\caption{Character and binary output tools}
\endfig
{\function y-or-n-p} and
{\function yes-or-no-p} are used to query the user.
%% 2.2.2 6
When the character {\tt \#{\char '134}Newline} is written to an output file,
the implementation must take the appropriate action
to produce a line division. This might involve writing out a
record or translating {\tt \#{\char '134}Newline} to a CR/LF sequence.
\endsubSection%{Character and Binary Input/Output}
\beginsubSection{Loading}
%% 23.4.0 1
To {\function load} a file is to treat its contents as code and execute
that code. The file may contain character data or binary data. If it is
charater data, {\function load}ing
is accomplished essentially by sequentially reading
the {\word forms} in the file, evaluating each immediately after it is read.
%% 23.4.0 2
{\function Load}ing a compiled
(``fasload'') file is similar, except that the file does not
contain text but rather pre-digested expressions created by the
compiler that can be {\function load}ed more quickly.
See ``Compilation''.
\endsubSection%{Loading}
∂01-Mar-89 1136 X3J13-mailer Section 1.5
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:36:49 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA02677; Wed, 1 Mar 89 11:34:49 PST
Message-Id: <8903011934.AA02677@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA02677; Wed, 1 Mar 89 11:34:49 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:23
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.5
%%Compliance
[{\it If the issue, CONFORMANCE-POSITION, undergoes radical modification
before passage, this section will change. Therefore, passage of this
section and CONFORMANCE-POSITION go hand in hand.}]
A conformity clause is a statement that is not part of
the language definition, but specifies requirements for compliance with the
language standard.
The standard presents the syntax and semantics to be implemented by
a conforming implementation.
A conforming implementation is an implementation
that processes
code that is written
in the language defined by the language standard, and
that obeys all the conformity clauses for
implementations written in the language standard.
Requirements for a conforming implementation:
\beginlist
\itemitem{1.} A conforming implementation is one that correctly
translates and executes conforming code.
\itemitem{2.} A conforming implementation
is one that rejects all
code that contains errors whose detection is required by this standard.
\itemitem{3.} A conforming implementation is one that contains no
variation except where the language standard permits, and specifies all
such permitted variations in the manner prescribed by this standard.
See ``Language Extensions''.
\itemitem{4.} A conforming implementation includes the following
in its accompanying documentation:
\beginlist
\itemitem{a.} A list of all definitions or values for the
implementation-defined features in the standard language.
See ``Implementation-defined Features''.
\itemitem{b.} A list of all the features of this implementation
which are not part of the standard language but which could unexpectedly
interact with user code, including all package names
and nicknames the implementation
uses.
\itemitem{c.} A statement of conformity, giving the complete reference to
this standard.
\endlist
\itemitem{5.} A conforming implementation shall meet the technical
specification in its accompanying documentation when related to the
requirements of this standard.
\itemitem{6.} A conforming implementation shall treat an
error as is outlined in ``Errors''.
\endlist
The basic test for conformance will be that code written to the letter
of the standard will run in all conforming implementations.
The basic rules are as follows:
\beginlist
\itemitem{1.}
Conforming code uses only the syntax specified in the standard.
\itemitem{2.}
Conforming code is written in only the sequence specified in the standard.
\itemitem{3.}
Conforming code is written using only the {\word functions}, {\word macros},
{\word special forms}, variables, and constants specified in this standard.
Use of language extensions to the syntax specified
in the standard, or dependence upon the existence of those extensions,
is not allowed in conforming code.
\itemitem{3.}
The definitions of all other {\word functions}, {\word macros}, or
{\datatype symbols}
that are used by the code must accompany
the code.
\itemitem{4.}
Conformance will not be machine-checkable.
\endlist
Portable code is required to produce equivalent results and
observable side effects in all conforming implementations.
It is possible for conforming code to
run in all conforming implementations, but to have allowable
implementation-dependent behavior that could make it non-portable.
∂01-Mar-89 1159 X3J13-mailer New versions of standard files available
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:59:21 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05099; Wed, 1 Mar 89 11:57:05 PST
Message-Id: <8903011957.AA05099@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA05099; Wed, 1 Mar 89 11:57:05 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:02
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: New versions of standard files available
New versions of the standard files that will be voted on in March are available
on hudson.dec.com. There will probably still be changes to section 5.1 (Errors),
so plan to copy and review that last. All these files are contained in
march-27-ballot.dvi, if you can use that file type. If you want to build this
yourself, use march-27-ballot.tex as well as the other files necessary for
any build (kcamfont.tex, kcmacros.tex, macros2.tex, march-27-ballot.tc).
S1100.SCOPE-PURPOSE-AND-HISTORY
S1200.ORGANIZATION-OF-THE-DOCUMENT
S1300.REFERENCED-PUBLICATIONS
S1400.DEFINITIONS
S1500.COMPLIANCE
S1600.IMPLEMENTATION-DEFINED-FEATURES
S1700.LANGUAGE-EXTENSIONS
S2100.INTRODUCTION
S2200.TYPES
S5100.ERRORS
S5200.INPUT-OUTPUT
S5300.INTERFACE-WITH-PROGRAMMING-ENVIRONMENT
S5400.GENERALIZED-REFERENCE
Please let me know if you have trouble accessing these files.
I will be mailing the sources to you for review.
kathy chapman
∂01-Mar-89 1203 X3J13-mailer Section 1.3
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:03:44 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05782; Wed, 1 Mar 89 12:01:39 PST
Message-Id: <8903012001.AA05782@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA05782; Wed, 1 Mar 89 12:01:39 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:22
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.3
%%Referenced Publications
\beginlist
\item{} {\it The Anatomy of Lisp}, John Allen, McGraw-Hill, 1978.
\item{} {\it Compile-time Evaluation and Code Generation for Semantics-directed
Compilers}, Andrew W. Appel, Carnegie-Mellon University, 1985.
\item{} {\it The Definition of Programming Languages}, Andrew D. McGettrick,
Cambridge University Press, 1980.
\item{} {\it Desiderata for the Standardisation of Lisp}, Julian Padget et.
al., 1986 ACM Conference on Lisp and Functional Programming, 1986.
\item{} {\it Formal Specification of Programming Languages - A Panoramic
Primer}, Frank G. Pagan, Prentice-Hall, Inc, 1981.
\item{} {\it $Revised↑3$ Report on the Algorithmic Language Scheme},
Jonathan Rees and William Clinger (editors), SIGPLAN Notices V21, \#12,
December, 1986.
%\item{} {\it Denotational Semantics}, David A. Schmidt, Allyn and Bacon,
%1986.
\item{} {\it Common LISP the Language}, Guy L. Steele, Jr., Digital Press,
1984.
%\item{} {\it Denotational Semantics: The Scott-Strachey Approach to Programming
%Language Theory}, Joseph E. Stoy, MIT, 1977.
\item{} {\it A Programmer's Guide to Common Lisp}, Deborah G. Tatar,
Digital Press, 1987.
\item{} {\it History of
Programming Languages}, edited by Richard Wexelblat, Academic Press,
1981.
\item{} {\it NIL -- A Perspective}, JonL White, MacSyma User's Conference,
1979.
\item{} {\it Common LISPcraft}, Robert Wilensky, W. W. Norton, 1986.
\endlist
∂01-Mar-89 1138 X3J13-mailer Section 1.6
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:38:01 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA02703; Wed, 1 Mar 89 11:35:58 PST
Message-Id: <8903011935.AA02703@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA02703; Wed, 1 Mar 89 11:35:58 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:23
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.6
%%Implementation-defined Features
The following sections contain lists of implementation-dependent
language characteristics.
For more
information about each of these implementation dependencies, see
Chapters 6 and 7 for the description of the {\word tool} being qualified.
\beginsubSection{Values}
%%\item{2.}
\beginlist
\item{1.}
An implementation determines the initial values of the {\word tools}
in Figure {\chapno--\the\capno}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt boole-clr}&{\tt boole-set}\cr
{\tt boole-1 }& {\tt boole-2}\cr
{\tt boole-c1}&{\tt boole-c2}\cr
{\tt boole-and}&{\tt boole-xor }\cr
{\tt boole-eqv}&{\tt boole-nand}\cr
{\tt boole-nor }&{\tt boole-orc1}\cr
{\tt boole-orc2}& \cr
& \cr
{\tt array-dimension-limit }&{\tt array-rank-limit }\cr
{\tt array-total-size-limit }&{\tt call-arguments-limit }\cr
{\tt multiple-values-limit}&{\tt lambda-parameters-limit }\cr
{\tt char-bits-limit }&{\tt char-code-limit }\cr
& \cr
@var[features] & {\tt internal-time-units-per-second} \cr
& \cr
{\tt most-positive-fixnum }&{\tt most-negative-fixnum } \cr
{\tt most-positive-short-float }&{\tt least-positive-short-float }\cr
{\tt most-positive-double-float }&{\tt least-positive-double-float }\cr
{\tt most-positive-long-float }&{\tt least-positive-long-float }\cr
{\tt most-positive-single-float }&{\tt least-positive-single-float }\cr
{\tt most-negative-short-float }&{\tt least-negative-short-float }\cr
{\tt most-negative-single-float }&{\tt least-negative-single-float }\cr
{\tt most-negative-double-float }&{\tt least-negative-double-float }\cr
{\tt most-negative-long-float }&{\tt least-negative-long-float }\cr
{\tt short-float-negative-epsilon }&{\tt single-float-negative-epsilon }\cr
{\tt double-float-negative-epsilon }&{\tt long-float-negative-epsilon }\cr
& \cr
@var[load-verbose] & @var[print-array] \cr
@var[print-pretty] &@var[random-state] \cr
@var[read-default-float-format] & \cr
\noalign{\vskip -9pt}
}}
\caption{Implementation-defined values}
\endfig
%%\item{42.}
\item{2.} The implementation determines the defaults for the
@Kwd[rehash-size] and
@Kwd[rehash-threshold]
arguments for
{\function make-hash-table}.
%%\item{44.}
\item{3.} The implementation determines the way in which a
{\datatype sequence} is initialized if an @Kwd[initial-element]
argument is not supplied. See {\function make-sequence}.
The implementation determines the way in which a
{\datatype string} is initialized if an @Kwd[initial-element]
argument is not supplied. See {\function make-string}.
Also, the implementation determines the way in which an
{\datatype array\/} is initialized if @Kwd[initial-element]\rm,
@Kwd[initial-contents]\rm, or @kwd[displaced-to]
arguments are not supplied. See {\function make-array\/}.
%%\item{58.}
\item{4.} Valid values for the argument to
{\function char-bit} and {\function set-char-bit}
are implementation-dependent.
\endlist
\endsubSection%{Values}
\beginsubSection{Results}
\beginlist
\item{1.}
%%12.5.2 7
An implementation may return the result of the
absolute value of a {\datatype complex}
number composed of {\datatype integer}
real and imaginary parts as either a {\datatype floating}-point
number or an {\datatype integer}. See {\function abs}.
%%\item{7.}
\item{2.}
An implementation determines the result returned from
{\function lisp-implementation-type},
{\function type-of},
{\function
lisp-implementation-version}, and {\function software-version}.
%%\item{18.}
\item{3.} An implementation determines the result of {\function digit-char}
when more than one character object can encode the supplied weight in
the given radix.
%%\item{20.}
\item{4.} An implementation may determine the consequences in
{\function do} and
{\function do{\tt $*$}} when the index variable is changed within the iteration
loop.
%%\item{30.}
\item{5.} The result of {\function
file-position} for a character file is implementation-dependent.
%%\item{34.}
\item{6.} An implementation determines the order of elements in the results
of {\function intersection},
{\function set-difference}, and {\function
union} and derivatives of those functions.
Some element-processing aspects of sorting are implementation-dependent.
See {\function sort}.
%%\item{36.}
\item{7.} Whether or not {\function length}
or any sequence operation returns when given a circular
{\datatype list} is implementation-dependent.
%%\item{39.}
\item{8.} The implementation determines the {\word type} of
the result of {\function log} ({\datatype integer} or {\datatype
floating-point})
when its arguments are both {\datatype integers} and the result is a whole
number.
%%\item{41.}
\item{9.} The implementation determines the result of {\function make-char}.
%%\item{46.}
\item{10.} An implementation determines the result of
{\tt (eq (symbol-name (make-symbol x)) x)}.
%%\item{47.}
\item{11.}
An implementation determines the {\word type}
of the result of {\function
max} and {\function min} in the following cases.
\beginlist
\itemitem{a.}
If the arguments are a mixture of {\datatype rationals} and
{\datatype floating-point}
numbers and the largest argument
is a {\datatype rational}.
\itemitem{b.} If the largest argument is a {\datatype floating-point}
number of a smaller format
than the largest format of any {\datatype floating}-point argument.
\endlist
In addition, if one or more of the arguments are equal, then any one
of them may be chosen as the value to return.
%%\item{62.}
%\item{12.} {\function special-form-p} can return a non-@nil\ value,
%the identity of which is implementation-dependent.
%%\item{63.}
\item{12.} If the argument to {\function sqrt} is an {\datatype integer},
the result may be either an {\datatype integer}
or a {\datatype float}ing-point number depending on the
implementation. Also, if the argument to {\function sqrt} is a negative
{\datatype integer},
the result
may be either a
{\datatype complex} number with {\datatype integer} components or
a {\datatype complex} number with {\datatype floating}-point components.
%%\item{64.}
\item{13.} If no characters in the argument to {\function string-trim},
{\function string-left-trim}, {\function string-right-trim},
{\function string-upcase}, {\function string-downcase}, and
{\function string-capitalize} need to be changed, then the implementation can
either return the argument itself or a copy of it.
This is true for all destructive
{\datatype sequence} functions.
%%\item{71.}
\item{14.} When the arguments to
a mathematical {\word function} are
all {\datatype rational} and the true mathematical result
is also (mathematically) rational, then unless otherwise noted
an implementation is free to return either an accurate result of
{\word type} {\datatype rational}
or a {\datatype single-float} approximation.
If the arguments are all {\datatype rational}
but the result cannot be expressed
as a {\datatype rational} number, then a {\datatype single-float}
approximation is always returned.
\endlist
\endsubSection%{Results}
\beginsubSection{Data Representation and Typing}
\beginlist
%%\item{5.}
\item{1.}
An implementation determines the representation of a byte specifier.
%%\item{9.}
\item{2.}
An implementation determines the {\word type} of the {\word object} returned
from {\function coerce} when the result is specified to be a specialized
type.
%%\item{11.}
\item{3.}
An implementation can define declaration specifiers other than the ones
given in the description of {\function declare}.
%%\item{27.}
\item{4.} An implementation determines the format of the environment
argument to {\function evalhook} and
the argument that comes to {\function defmacro} via \&environment; the
{\function defmacro} and
{\function evalhook} environment arguments are not necessarily in the same
format.
%%\item{75.}
\item{5.} The existence of
{\word types} that are not {\word subtypes} of {\datatype common}
is implementation-dependent.
\endlist
\endsubSection%{Data Representation and Typing}
\beginsubSection{Program and Control Structure}
\beginlist
%%\item{13.}
%\item{1.}
%An implementation
%may or may not check for any dynamic {\word bindings}
%of the first argument to {\function defconstant} at the time
%{\function defconstant} is executed.
%%\item{14.}
\item{1.}
An implementation determines the way that {\function defmacro}
actually installs a macro function.
%%\item{15.}
\item{2.}
An implementation determines the code generated by {\function defsetf}.
%%\item{16.}
\item{3.}
The following are implementation-dependent features of {\function defstruct}:
\beginlist
\itemitem{a.} The initial contents of a slot, when they have not been provided,
are specified by the implementation.
\itemitem{b.} The access functions may be declared {\function inline}.
\itemitem{c.} The incorrect use of access functions may or may not be checked
by an implementation.
\itemitem{d.} For included slots, an implementation may or may not check
{\word type} assignments.
\itemitem{e.} If the {\keyword :type} option is not supplied, the implementation
determines the representation of the {\datatype structure}.
%%(see clean-up issue)
\endlist
%%\item{35.}
\item{4.} The permissibility of non-standard {\word lambda-list}
keywords is implementation-dependent.
%%\item{40.}
\item{5.}
An implementation is free
to implement as a {\word special form} any {\word construct}
described in this standard as a {\word macro},
if an equivalent {\word macro} definition is also provided.
See {\function macro-function}.
%%\item{60.}
\item{6.}
The exact expansion for any particular form given to {\function setf}
may be implementation-dependent.
%%\item{76.}
\item{7.} The internal representation of
a backquoted {\word form} is implementation-dependent.
\endlist
\endsubSection%{Program and Control Structure}
\beginsubSection{Comparisons}
\beginlist
%%\item{6.}
\item{1.}
An implementation determines the way font information is compared in the
functions {\function char-equal, char-not-equal, char-lessp, char-greaterp,
char-not-greaterp}, and {\function char-not-lessp}. Where not
specified by this standard, the ordering of
characters is implementation-dependent.
\endlist
\endsubSection%{Comparisons}
\beginsubSection{Numerical Calculations}
\beginlist
%%\item{8.}
\item{1.} {\function minusp},
{\function eql},
{\function float-sign}, and
{\function zerop}
are affected by the presence
of {\tt $-0.0$} in an implementation.
%%\item{24.}
\item{2.} Whether or not two {\datatype numbers} or {\datatype characters}
are {\function eq}
depends on the implementation.
%%\item{26.}
\item{3.} Whether two {\datatype floating}-point
numbers of different {\word types} are {\function eql} depends
on the implementation because it is possible for an implementation to
have less than four floating-point data types.
%%%\item{29.}
%\item{4.} An implementation may use different algorithms
%for the cases of a {\datatype rational} second
%argument and a {\datatype floating}-point
%second argument to {\function expt}.
%%\item{55.}
\item{4.} Random number generation is implementation-dependent.
%%\item{70.}
\item{5.} For the {\word operators} in Figure {\chapno--\the\capno},
an implementation may process the arguments in any manner consistent
with associative (and possibly commutative) rearrangement.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0
plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt + }&{\tt * }&{\tt max }\cr
{\tt min }&{\tt =}&{\tt /=}\cr
{\tt < }&{\tt >}&{\tt <=}\cr
{\tt >= }&{\tt gcd}&{\tt lcm}\cr
{\tt logior}&{\tt logxor}&{\tt logand}\cr
{\tt logeqv}&{\tt lognand}&{\tt lognor}\cr
{\tt logandc1}&{\tt logandc2}&{\tt logorc1}\cr
{\tt logorc2}&{\tt boole}&\cr
\noalign{\vskip -9pt}
}}
\caption{Mathematically associative operators}
\endfig
Implementations may differ in
which automatic coercions are applied because of differing
orders of argument processing.
%%\item{72.}
\item{6.}
The precise definitions of {\datatype short-float},
{\datatype long-float}, {\datatype single-float}, and
{\datatype double-float} are implementation-dependent.
\endlist
\endsubSection%{Numerical Calculations}
\beginsubSection{User Interface}
\beginlist
%%\item{.}
\item{1.}
An implementation determines the user interface for the read-eval-print loop
in the {\word
operators} and variables in Figure {\chapno--\the\capno}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0
plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt break }&{\tt check-type }&{\tt describe }\cr
{\tt disassemble }&{\tt inspect }&{\tt step }\cr
{\tt warn }&{\tt y-or-n-p }&{\tt yes-or-no-p }\cr
{\tt error }&{\tt cerror }&{\tt ccase }\cr
{\tt ccase }&{\tt ctypecase }&{\tt Anything that uses cerror }\cr
\noalign{\vskip -9pt}
}}
\caption{User interface operators and variables}
\endfig
\endlist
\endsubSection%{User Interface}
\beginsubSection{Input/Output}
\beginlist
%%\item{17.}
\item{1.} An implementation determines whether an attempt by {\function
delete-file} to delete a non-existent file is considered to be successful.
%%\item{19.}
\item{2.} An implementation may define keywords to be used with
{\function directory}.
%%\item{31.}
\item{3.} An implementation determines the precise actions of
{\function finish-output}, {\function clear-output}, and {\function
force-output}.
%%\item{31a.}
\item{4.} {\datatype Streams}
may be implemented in an asynchronous or buffered manner.
%%\item{32.}
\item{5.} {\function format} has the following implementation-defined
features:
\beginlist
%% CLean-up item on this
\itemitem{a.} {\tt @tilde C} prints a character in an implementation-dependent
abbreviated format.
\itemitem{b.} The precise output for {\tt @tilde :{\char '100}C} depends
on the implementation.
\itemitem{c.} When rounding up and rounding down would produce printed values
equidistant from the scaled value of the argument, then the implementation
is free to use either one.
\itemitem{d.} For the {\tt @tilde \$} operation, if the magnitude of the argument is so large or small
that more than 100 digits would have to
be printed, then an implementation is free, at its discretion, to print
the number using exponential notation.
\itemitem{e.} For the {\tt @tilde \$} operation, if
the argument is a {\datatype rational} number,
then it is coerced to be a {\datatype single-float}
or processed by any other method that has essentially the
same behavior.
Only a finite number of digits may be printed.
\endlist
%%\item{37.}
\item{6.} The means by which a text (character file)
is distinguished from an object (binary) file is
implementation-dependent.
%%\item{38.}
\item{7.} The selection by {\function load} of a file type when there
is a choice is implementation-dependent.
%%\item{43.}
\item{8.} The implementation determines the internal representation
of a {\datatype pathname}. See {\function make-pathname}.
%%\item{48.}
\item{9.} The following aspects of {\function open}
are implementation-dependent:
\beginlist
\itemitem{a.} {\keyword :supersede}
\itemitem{b.} An implementation is required to recognize all of
the following {\keyword if-exists} keywords
and to do something reasonable in the context of the host operating
system:
{\keyword :error},
{\keyword :new-version},
{\keyword :rename},
{\keyword :rename-and-delete},
{\keyword :overwrite},
{\keyword :append},
{\keyword :supersede}, or
@false\rm.
\itemitem{c.} If it is impossible for an implementation to handle some option
in a manner close to what is specified in this manual, an error may be
signalled.
\endlist
%%\item{50.}
\item{10.} {\function parse-namestring}
may or may not signal an error if
the representation of a {\datatype pathname}
is surrounded on either side by
whitespace characters, depending on the implementation.
Whether or not {\function parse-namestring} supplies
the
standard default device as the device component
of the resulting {\datatype pathname} depends on the implementation.
%%\item{51.}
\item{11.} The {\datatype pathname} namestring
syntax is implementation-dependent.
The printed representation of a pathname
typically designates {\keyword :wild} by an asterisk; however, this is
implementation-dependent.
%%\item{52.}
\item{12.} A {\datatype character} name or a {\datatype pathname}
that is typed out
is acceptable as input in only the implementation which typed it.
Which names for characters are chosen to print is
implementation-dependent, although standard names are
chosen over non-standard names. See {\function write}.
%%\item{53.}
\item{13.} The printed representation of a
{\datatype random-state} object is implementation-dependent.
%%\item{54.}
\item{14.} {\word Objects} which do not have a specific syntax
specified in this manual are printed in an implementation-dependent manner.
%%\item{68.}
\item{15.} The {\arg host}
argument to {\function user-homedir-pathname}
defaults in an implementation-dependent manner.
%%\item{77.}
\item{16.} Whether the following
character names are supported is implementation-dependent:
@f[rubout]\rm, @f[page]\rm,
@f[tab]\rm,
@f[backspace]\rm,
@f[return]\rm, and
@f[linefeed]\rm.
%%\item{78.}
\item{17.} Whether
characters with non-zero {\arg bits} and {\arg font} attributes
syntax
descriptions are in the {\datatype readtable} is implementation-dependent.
\endlist
\endsubSection%{Input/Output}
\beginsubSection{Compiling}
\beginlist
%%\item{10.}
\item{1.}
An implementation determines the following for {\function compile-file}:
\beginlist
\itemitem{a.} The contents of the file created by {\function compile-file}.
\itemitem{b.} The file
specification (if one is not supplied)
for the file created by {\function compile-file}.
\endlist
%%\item{12.}
\item{2.}
An implementation's compiler can ignore declaration
specifiers except for {\tt declaration}, {\tt special}, and
{\tt notinline}.
%%\item{25.}
\item{3.} An implementation may ``collapse'' constants or portions of constants
in code to be compiled if they appear to be {\function eq}
or {\function eql} and are {\function equal}.
See ``Compilation''.
%%\item{79.}
\item{4.} The representation of the {\word object} produced by
the compiler, and the internals of the compiler
are implementation-dependent, except that {\function compile} produces
a {\datatype compiled-function}.
\endlist
\endsubSection%{Compiling}
\beginsubSection{Miscellaneous}
\beginlist
%%\item{4.}
\item{1.}
An implementation determines the specifics of the
debugger that {\function break} enters.
%%\item{74.}
\item{2.} Although functions that manipulate {\datatype packages}
generally signal
name conflict errors before making any change to the package structure, an
implementation may {\function export}
each of a given list of {\datatype symbols} separately.
%%\item{49.}
\item{3.} The contents of the @f[system] package are determined by
the implementation.
%%\item{57.}
\item{4.} The frequency of execution of test and key
functions for all sequence functions is implementation-dependent.
The implementation of
{\function search} may choose to search the {\datatype sequence} in any order.
%%\item{65.}
\item{5.} The manner in which a
hash code is computed by {\function sxhash}
is implementation-dependent.
%% clean-up pending for this
%%\item{69.}
\item{6.} The optional argument {\arg extension}
for {\function
vector-push-extend}
defaults to a ``reasonable'' implementation-dependent
value.
%%\item{73.}
\item{7.} A {\datatype symbol's} property list may have defined components.
\endlist
\endsubSection%{Miscellaneous}
\beginsubSection{Programming Environment}
\beginlist
%%\item{22.}
\item{1.} An implementation may or may not provide a resident editor.
See {\function ed}.
%%\item{23.}
\item{2.} An implementation determines the means by which
function text is obtained when {\tt (ed {\it symbol})} is invoked.
%%\item{33.}
\item{3.} An implementation determines the units used in representing
Internal Time.
See {\function get-internal-run-time}.
%%\item{56.}
\item{4.} The information {\function room} prints is
implementation-dependent.
%%\item{66.}
\item{5.} The nature and
format of the information printed by {\function time}
is implementation-dependent.
%%\item{67.}
\item{6.} The following are implementation dependencies of
tracing.
\beginlist
\itemitem{a.} {\function trace} and {\function untrace} may accept
implementation-dependent argument formats.
\itemitem{b.} The format of the {\function trace}
output is implementation-dependent.
\endlist
\endlist
\endsubSection%{Programming Environment}
∂01-Mar-89 1207 X3J13-mailer Section 2.1
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:06:27 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA06314; Wed, 1 Mar 89 12:04:26 PST
Message-Id: <8903012004.AA06314@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA06314; Wed, 1 Mar 89 12:04:26 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:24
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.1
%% Introduction to Objects and Types
%% 2.0.0 4
%% 6.2.1 1
A {\word data type} (a {\word type})
is a (possibly infinite) set of
{\word objects}. An {\word object} can belong to more than one
{\word type}. @Funref[typep] is used to determine
whether an {\word object} is of a given {\word type},
a set membership test, while {\function subtypep}
is a subset test.
@Funref[type-of] returns a {\word type}
to which an {\word object} belongs.
%% 9.1.0 1
Type declarations can be embedded in executable
code using {\function declare}.
Global type declarations are established by {\function proclaim}.
%% 9.3.0 1
%The special form {\function the} is used to declare
%the {\word type} of the value of an
%unnamed {\word form}.
%The form {\tt (the type form)} means
%that the value of {\tt form}
%is declared to be of type {\tt type}.
%% 1.1.0 4
%% 9.0.0 3
%All type declarations are optional
%and correct type declarations do not affect the meaning
%of a correct program.
%All type declarations are of an advisory nature, and may be used
%by the @xlisp\ system in performing error checking
%or producing more efficient compiled code.
%% 9.0.0 4
The consequences are undefined if a program violates a
type declaration (such as a {\function type} declaration),
but an implementation is
not required to detect such errors.
%% 9.2.0 1
%% 2.0.0 1
Data {\word objects}, not variables, are {\word typed}.
Normally, any variable
can have any @xlisp\ {\word object} as its value.
It is possible to make an explicit
type declaration that a variable will
take on one of only a limited set of values.
%% 2.0.0 5
@clisp\ {\word types} are arranged in a directed acyclic graph.
%Therefore,
%it is possible for an {\word object} to belong to more than one
%{\word type}.
%% 2.12.0 1
%%% 19.1.0 1
%{\word Structures} created by @Macref[defstruct]
%are instances of user-defined {\word types}.
%%% Beginning of CLOS stuff
%\beginSection{Introduction}
%
The \CLOS\ is based on
{\word generic functions}, multiple inheritance, declarative {\word method}
combination, and a meta-object protocol.
%
%The first two chapters of this specification present a description of
%the standard Programmer Interface for the \CLOS. The first chapter
%contains a description of the concepts of the \CLOS, and the second
%contains a description of the functions and macros in the \CLOS\
%Programmer Interface. The chapter ``The \CLOS\ Meta-Object
%Protocol'' describes how the \CLOS\ can be customized.
%
The fundamental {\word objects} of the \CLOS\
are {\word classes}, {\word instances},
{\word generic functions}, and {\word methods}.
A {\bit class\/} object determines the structure and behavior of a set
of other {\word objects}, which are called its {\bit instances}.
Every {\word object} is an {\bit
instance\/} of a {\word class}. The
{\word class} of an {\word object} determines the set of
operations that can be performed on the {\word object}.
See ``Generic Functions and Methods''.
%%\endSection%{Introduction}
∂01-Mar-89 1232 X3J13-mailer Section 1.2
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:32:32 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA09839; Wed, 1 Mar 89 12:30:26 PST
Message-Id: <8903012030.AA09839@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA09839; Wed, 1 Mar 89 12:30:26 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:21
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.2
%%Organization of the Document
This document is divided into seven chapters:
\beginlist
\item{\bull} This introduction.
\item{\bull} A description of @clisp\ types and objects.
\item{\bull} A description of the syntax of @clisp\ objects.
\item{\bull} The @clisp\ evaluation and compilation processes.
\item{\bull} A description of the @clisp\ interfaces to
its environment and a description of the condition
system.
\item{\bull} A catalog of @clisp\ symbols (divided into two chapters).
\endlist
∂01-Mar-89 1232 X3J13-mailer Section 1.1
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:32:28 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA09717; Wed, 1 Mar 89 12:30:00 PST
Message-Id: <8903012030.AA09717@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA09717; Wed, 1 Mar 89 12:30:00 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:21
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.1
%%Scope, Purpose, and History
\beginsubSection{Scope and Purpose}
The standard specification set forth in this document
is designed to promote the portability of @clisp\ programs
among a variety of data-processing systems. It is intended for use
by implementors and knowledgeable programmers, and is not a tutorial.
This standard is intended to be a language specification
rather than an implementation specification.
An
implementation is free to achieve the semantics
specified in this standard by any means. The @clisp\ definitions
in Chapters 6 and 7 need not be reflected directly in the implementation.
\endsubSection%{Scope and Purpose}
\beginsubSection{History}
Lisp is the second oldest high-level programming language still in current use.
(The oldest high-level programming language still in widespread use
is Fortran.)
@clisp\ is a joint-venture language stemming from several
research and development projects in the late 1970's. Its
roots reveal why some of the features of the language were
added. From a short look at these roots, it can also be seen
how these features influence the architectural requirements
for a high-quality implementation.
From the mid-1960's through much of the 1970's, DEC's PDP10 computer
was the mainstay of Lisp work at MIT and Stanford's AI and Computer
Science Labs, at BBN in Cambridge, at CMU, and at selected other sites.
Designed in the early
1960's, the PDP10 had the unique advantage of being influenced by
John McCarthy, the ``Grandfather of Lisp'', and as a result has
half-word instructions suitable for {\word car} and {\word cdr}
instructions, and
stack instructions to facilitate recursive programming.
But the limitations of this old machine were painfully
evident by 1973, two of which were
the high cost to support a single researcher,
and the small address space available ($2↑{18}$ = 262,144 words).
To alleviate the latter problem, BBN Lisp (developed at Bolt, Bernak,
\& Newman in Cambridge, and later, with Xerox's
participation, called Interlisp)
added a ``black hole'' feature somewhat akin to ``paging''
on a function basis rather than on a page-boundary basis. MacLisp
(developed at the MIT AI Lab and Laboratory for Computer Science)
added an ``autoload'' feature, whereby only the functions actually used
would be loaded in to ``core''. Large applications such as the
symbolic algebra system MACSYMA and the Interlisp programing development
environment were driving forces for larger address space capabilities.
In the early 1970's, at Xerox's Palo Alto Research Center, L. Peter Deutch
conceived of a personal workstation with an architecture
tailored to the needs of Lisp. This architecture would allow
a machine to be affordable to an
individual researcher and to have sufficient power to run large Lisp
applications.
Soon thereafter, Richard Greenblatt began work
on a similar design at MIT's AI Laboratory.
Eventually, a dialect of Interlisp known as Interlisp-D became available
on
the ``D-series'' machines manufactured by Xerox, and an upward-compatible
extension of MacLisp became available on the early MIT ``Lisp'' machines.
Both of these efforts culminated in commercial Lisp machines that were
seen in laboratory prototype at about the time of the 1980 Lisp Conference
at Stanford, and were marketable by 1981.
In another direction, in the late 1970's the MacSyma group at MIT
began
a project called New Implementation of Lisp (NIL). In additon
to capitalizing on the large address space and other hardware
capabilities of the VAX, one of the stated goals of NIL was to fix many
of the historic, but annoying, little problems of the Lisp
language while still retaining an essentially upward-compatible
outlook. At about the same time, a research group
at Stanford University and Lawrence Livermore National Laboratory
began the design of a Lisp to run on the supercomputer,
S-1. Recognizing the similarity of
their goals to those of the MIT NIL project, the S-1 group
began to collaborate with the NIL group.
In a third direction, around 1980, Scott Fahlman and others at CMU
began work on a Lisp to run on the SPICE workstation.
The SPICE machine had a much weaker microcode capability
than the MIT Lisp Machine, so the goal was to emulate as much of the
MIT design as was feasible.
After a DARPA-sponsored meeting on the future of Lisp in April 1981,
representatives
of several of the post-MacLisp efforts (Gabriel, Steele, White, and Fahlman)
decided to join forces by
directing their efforts towards a common, portable dialect of Lisp.
Further design sessions were held at CMU in June 1981. Later that
fall, Symbolics Corporation representatives began assisting in
designing the new dialect.
After the name was chosen (@clisp) the task then turned to a
choice of how much of the design could be retained from the Lisp
machines, and how much seemed to pre-suppose special purpose hardware. Also
there was a task of sorting out which features of conventional
languages for conventional hardware architectures, like compile-time
typing, could be integrated into the new language without damaging
its essential Lisp character. The theorists of each
camp allowed some deviations from what they considered theoretically
best, and the result
was a language suitable for general purpose hardware, but with certain
particular implementational problems to be met.
@maclisp, @lmlisp, @scheme, @interlisp, @slisp, @s1lisp, @newlisp,
@stdlisp, and @psl\
were each considered during the design of
@clisp\rm, and the most useful features of each were incorporated.
{\it Common LISP the Language},
was written by members of the informal design group.
The semantics in {\it Common LISP the Language} were intentionally
underspecified in
places where it was felt that a tight specification would
unduly constrain @clisp\ research and use.
However, industrial use of @clisp\
mandates implementations to produce the same results given the same arguments
in order that code can be ported between implementations.
In addition, @clisp\ users recognized the need to agree on standard
object-oriented and condition systems, iteration facilities, and
a way to handle large character sets.
Therefore, a new language specification, this document, was created by
the X3J13 committee.
\endsubSection%{History}
∂01-Mar-89 1234 X3J13-mailer Section 1.4
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:34:33 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA09935; Wed, 1 Mar 89 12:32:23 PST
Message-Id: <8903012032.AA09935@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA09935; Wed, 1 Mar 89 12:32:23 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:22
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.4
%%Definitions
This section contains notational conventions used in this manual.
The font key to be used in Chapters 1-5
is as follows:
\beginlist
\itemitem{\datatype data-type}
Denotes
@clisp\ {\word data types}.
\itemitem{\word defined word}
Denotes the words whose
definitions appear in the ``Glossary''.
\itemitem{\function tools}
Denotes {\word tools}.
\itemitem{\keyword keywords}
Denotes {\word keywords}.
\endlist
%% 1.2.1 1
All numbers in this book are in decimal notation
unless otherwise noted.
%% 1.2.5 9
The dot appearing in the expression
@f[(sample-macro @i[var] {\char '056} @i[body])]
means that @f[body] stands
for a list of {\word forms},
not just a single {\word form}, at the end of a list.
The following notations are used in this document:
\beginlist
\itemitem{\word @EV\rm}
Indicates {\word evaluation}.
For example:
@Lisp
(+ 4 5) @EV 9
@Endlisp
means that the result of {\word evaluating} the code @f[(+ 4 5)] is @f[9]\rm.
%% 1.2.3 3
\itemitem{\word @EQ}
Indicates code
equivalence.
For example:
@Lisp
(gcd x (gcd y z)) @EQ (gcd (gcd x y) z)
@Endlisp
means that the results and observable
{\word side-effects} of {\word evaluating }
the {\word form}
@f[(gcd x (gcd y z))] are always the same as the results
and observable {\word side-effects} of
@f[(gcd (gcd x y) z)] for any
@f[x]\rm, @f[y]\rm, and @f[z]\rm.
%% 1.2.5 4
\itemitem{@t}
The canonical truth value.
Any {\word object} other than @false\ is construed to be Boolean
``not false,'' that is, ``true.'' The {\datatype symbol} @true\ is
used to mean ``true'' when no other value is more appropriate.
When a {\word function} is said to ``return @i[true]\rm'' or to ``be @i[true]\rm''
in some circumstance, this means that it returns some value other
than @false\rm, but not necessarily @true\rm.
\itemitem{@nil}
Represents the empty {\datatype list} and
the ``false'' value for Boolean tests.
The {\datatype symbol} @f[nil] evaluates to
itself, so @f['nil] and @f[nil] denote the same {\word object}
in terms of evaluation.
The former syntax is used to emphasize that the result is
a {\datatype symbol},
while the latter is used to emphasize that the result is
a boolean value. @f['()]
is used to denote the
empty {\datatype list}
in terms of evaluation. It is used in a quoted structure
or a program structure.
For example:
\screen!
(print ()) ;avoided
'(nil nil) ;list of symbols
'(()()) ;list of empty lists
(defun three () 3) ;Emphasize empty parameter list.
(append '() '()) @EV () ;Emphasize use of empty lists
(not @false) @EV @true ;Emphasize use as Boolean "false"
(get '@nil 'color) ;Emphasize use as a symbol
\endscreen!
When a function is said to ``return @i[false]\rm'' or to ``be @i[false]\rm''
in some circumstance, this means that it returns @false\rm.
\endlist
∂01-Mar-89 1240 X3J13-mailer Section 5.3
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:40:11 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA10373; Wed, 1 Mar 89 12:38:09 PST
Message-Id: <8903012038.AA10373@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA10373; Wed, 1 Mar 89 12:38:09 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:26
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 5.3
%% Interface with the Programming Environment
\beginSubsection{Top level loop}
%% 20.2.0 1
The {\function read}-{\function eval}-{\function print} loop
is the highest level of control and consists of an endless
loop that reads an expression, evaluates it, and prints the
results. The parts of the
{\function read}-{\function eval}-{\function print} loop are individually
referred to as the reader, the evaluator, and the printer.
%% 20.2.0 2
The precise nature of the {\function read}-{\function eval}-{\function print}
loop
is not rigorously specified; thus the user interface is
implementation-defined.
%% 20.2.0 3
The {\function read}-{\function eval}-{\function print} loop
traps all {\function throws} and recovers from them.
It prints all values resulting from the evaluation of a
{\word form}.
%% 20.2.0 4
The following variables are maintained by the
{\function read}-{\function eval}-{\function print} loop.
{\tt +, ++, +++, *, **, ***, /, //, ///, -}.
See Chapter 6 for the meanings of these variables.
\endSubsection%{Top level loop}
\beginSubsection{Environment inquiry}
%% 25.4.0 1
Environment inquiry {\word tools} provide information about the
system on which a @clisp\ program is being executed.
These {\word tools}
aid in querying the hardware and software configuration, and
in debugging.
Figure {\chapno--\the\capno} lists the
{\word tools} that are applicable to configuration inquiry.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt @var[features] } & {\tt long-site-name } & {\tt room } \cr
{\tt identity } & {\tt machine-instance } & {\tt short-site-name } \cr
{\tt lisp-implementation-type } & {\tt machine-type } & {\tt software-type }
\cr
{\tt lisp-implementation-version} & {\tt machine-version } & {\tt
software-version } \cr
\noalign{\vskip -9pt} }}
\caption{Configuration inquiry tools}
\endfig
Figure {\chapno--\the\capno} lists the
{\word tools} that are applicable to debugging.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt apropos } & {\tt dribble } & {\tt step } \cr
{\tt apropos-list } & {\tt ed } & {\tt trace } \cr
{\tt describe } & {\tt inspect }& {\tt untrace } \cr
{\tt documentation } & & \cr
\noalign{\vskip -9pt} }}
\caption{Debugging tools}
\endfig
\endSubsection%{Environment inquiry}
\beginsubsubsection{Time}
%% 25.4.1 1
Time is represented in three different ways in @clisp\rm:
Decoded Time, Universal Time, and Internal Time.
The first two representations
are used primarily to represent calendar time, and are
precise only to one second.
Internal Time is used primarily to represent measurements of computer
time (such as run time) and is precise to some implementation-dependent
fraction of a second, as specified by @Conref[internal-time-units-per-second]\rm.
Decoded Time format is used only for absolute time indications.
Universal Time and Internal Time formats are used for both absolute
and relative times.
\beginlist
\itemitem{\bf Decoded time}
%% 25.4.1 2
Decoded Time format represents calendar time as a number of components:
%% 25.4.1 3
\beginlist
\itemitem{\bf Second}
An {\datatype integer} between 0 and 59, inclusive.
%% 25.4.1 4
\itemitem{\bf Minute}
An {\datatype integer} between 0 and 59, inclusive.
%% 25.4.1 5
\itemitem{\bf Hour}
An {\datatype integer} between 0 and 23, inclusive.
%% 25.4.1 6
\itemitem{\bf Date}
An {\datatype integer} between 1 and 31, inclusive (the upper limit actually
depends on the month and year, of course).
%% 25.4.1 7
\itemitem{\bf Month}
An {\datatype integer} between 1 and 12, inclusive; 1 means January,
12 means December.
%% 25.4.1 8
\itemitem{\bf Year}
An {\datatype integer} indicating the year A.D. However, if this
{\datatype integer}
is between 0 and 99, the ``obvious'' year is used; more precisely,
that year is assumed that is equal to the
{\datatype integer} modulo 100 and
within fifty years of the current year (inclusive backwards
and exclusive forwards).
Thus, in the year 1978, year 28 is 1928
but year 27 is 2027. (Functions that return time in this format always return
a full year number.)
%% 25.4.1 10
\itemitem{\bf Day-of-week}
An {\datatype integer} between 0 and 6, inclusive;
0 means Monday, 1 means Tuesday, and so on; 6 means Sunday.
%% 25.4.1 11
\itemitem{\bf Daylight-saving-time-p}
A flag that, if not @false\rm, indicates that
daylight saving time is in effect.
%% 25.4.1 12
\itemitem{\bf Time-zone}
%% should be a clean-up item about this
An {\datatype integer} specified as the number of hours west of GMT
(Greenwich Mean Time). For example, in Massachusetts the time zone is 5,
and in California it is 8. Any adjustment for daylight saving time is
separate from this.
\endlist
\itemitem{\bf Universal time}
%% 25.4.1 13
Universal Time represents time as a single non-negative {\datatype integer}.
For relative time
purposes, this is a number of seconds. For absolute time, this is the
number of seconds since midnight, January 1, 1900 GMT. Thus the time 1
is 00:00:01 (that is, 12:00:01 a.m.) on January 1, 1900 GMT.
Similarly, the time 2398291201 corresponds to time 00:00:01 on January 1,
1976 GMT.
Recall that the year 1900 was not a leap year; for the purposes of
@clisp\rm, a year is a leap year if and only if its number is divisible by 4, except
that years divisible by 100 are not leap years, except that years
divisible by 400 are leap years. Therefore the year 2000 will
be a leap year.
(Note that the ``leap seconds'' that
are sporadically inserted by the world's official timekeepers as an additional
correction are ignored; @clisp\ assumes that every day is exactly 86400
seconds long.)
Because the @clisp\ Universal Time representation uses only
non-negative integers, times before the base time of midnight,
January 1, 1900 GMT cannot be processed by @clisp\rm.
\itemitem{\bf Internal time}
%% 25.4.1 14
Internal Time also represents time as a single {\datatype integer},
in terms of an implementation-dependent unit.
Relative time is measured as a number of these units.
Absolute time is relative to an arbitrary time base.
\endlist
Figure {\chapno--\the\capno} lists the
{\word tools} that are applicable to time.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt time }&{\tt get-decoded-time }\cr
{\tt get-universal-time }& {\tt decode-universal-time }\cr
{\tt encode-universal-time } & {\tt internal-time-units-per-second } \cr
{\tt get-internal-run-time }&{\tt get-internal-real-time }\cr
{\tt sleep } & \cr
\noalign{\vskip -9pt} }}
\caption{Time tools}
\endfig
\endsubsubsection%{Time}
∂01-Mar-89 1243 X3J13-mailer Section 5.4
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:43:35 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA10362; Wed, 1 Mar 89 12:41:24 PST
Message-Id: <8903012041.AA10362@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA10362; Wed, 1 Mar 89 12:41:24 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:27
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 5.4
%% Generalized Reference
When it is stated that an argument to a {\word function} or
{\word macro} must be
a generalized reference, this means that the argument must follow the
rules specified in this section. The definition for generalized reference
is given in terms of {\function setf},
which performs access and update operations within the
same {\word form}.
Figure {\chapno--\the\capno} contains examples of the use of {\function setf}.
Note that the values returned by evaluating the {\word forms} in column two
are not necessarily the same as those obtained by evaluating the {\word
forms}
in column three.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
\hfil\bf Access function & Update function & Update using {\function setf} \cr
\noalign{\vskip 2pt\hrule\vskip 2pt}
{\tt x }&{\tt (setq x datum) }&{\tt (setf x datum) }\cr
{\tt (car x) }&{\tt (rplaca x datum) }&{\tt (setf (car x) datum) }\cr
{\tt (symbol-value x) }&{\tt (set x datum) }&{\tt (setf (symbol-value x) datum) }\cr
\noalign{\vskip -9pt}
}}
\caption{Examples of setf}
\endfig
Figure {\chapno--\the\capno} lists the {\word operators}
that are applicable to generalized reference. Some manipulate generalized
references and some manipulate {\function setf} methods.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt setf }&{\tt psetf }&{\tt shiftf }\cr
{\tt rotatf }&{\tt getf }&{\tt remf }\cr
{\tt incf }&{\tt decf }&{\tt push}\cr
{\tt pop }&{\tt assert }&{\tt ctypecase }\cr
{\tt ccase} &{\tt define-modify-macro }&{\tt defsetf }\cr
{\tt define-setf-method }&{\tt get-setf-method }&{\tt get-setf-method-multiple-value }\cr
\noalign{\vskip -9pt}
}}
\caption{Generalized reference operators}
\endfig
%% 7.2.0 29
%% 7.2.0 30
These {\word operators} must guarantee that
subforms of generalized references are
evaluated
exactly as many times as they appear in the source program, and
they are evaluated
in exactly the same order as they appear in the source
program
\issue{PUSH-EVALUATION-ORDER}
(left to right)
whenever possible. The left-to-right rule does not
remove the obligation on writers of {\word macros} and
users of {\function define-setf-method}
to ensure
left-to-right order, however.
\endissue{PUSH-EVALUATION-ORDER}
\issue{PUSH-EVALUATION-ORDER}
\beginlist
\itemitem{1.}
The evaluation ordering of subforms within a generalized reference
is determined by the order specified by the second value returned by
{\function get-setf-method}.
For all predefined generalized references ({\function getf}, {\function ldb}),
this order of evaluation is exactly left-to-right. When a generalized
reference is derived from a macro expansion, this rule is applied after the
macro is expanded to find the appropriate generalized reference.
If the user writes a {\function defmacro} or
{\function define-setf-method}
that does not preserve order, the order specified in the
user's code holds. For example, given
@lisp
(defmacro wrong-order (x y) `(getf ,y ,x))
@endlisp
then
@lisp
(push value (wrong-order place1 place2))
@endlisp
will evaluate {\tt place2} first and then {\tt place1}
because that is the order they
are evaluated in the macro expansion.
\itemitem{2.}
For the {\word macros}
that manipulate generalized references ({\function push},
{\function pushnew}, {\function getf\/}, {\function remf\/},
{\function incf\/}, {\function decf\/}, {\function shiftf\/}, {\function rotatef\/},
{\function psetf\/}, {\function setf\/}, {\function pop}, and those
defined by {\function define-modify-macro}) the subforms of the
macro call are evaluated exactly once
in left-to-right order, with the subforms of the generalized references
evaluated in the order specified in (1).
{\function push}, {\function pushnew}, {\function getf\/}, {\function remf\/},
{\function incf\/}, {\function decf}, {\function shiftf\/}, {\function rotatef\/},
{\function psetf\/}, {\function pop} evaluate all
subforms before modifying any of the generalized reference locations.
{\function setf\/} (in
the case when {\function setf\/} has more than two arguments)
performs its operation
on each pair in sequence, i.e., in
@lisp
(setf place1 value1 place2 value2 ...)
@endlisp
the subforms of {\tt place1} and {\tt value1} are evaluated, the location
specified by
{\tt place1} is modified to contain the value returned by
{\tt value1}, and
then the rest of the {\function setf\/} form is processed in a like manner.
\itemitem{3.}
For {\function check-type}, {\function ctypecase}, and
{\function ccase}, subforms of the generalized
reference are evaluated once as in (1), but may be evaluated again if the
type check fails in the case of {\function check-type}
or none of the cases hold in
{\function ctypecase} and {\function ccase}.
\itemitem{4.}
For {\function assert}, the order of evaluation of the generalized
references is not specified.
\endlist
Rules 2, 3 and 4 cover all macros defined in @clisp\ that manupulate
generalized references.
@lisp
(let ((ref2 (list '())))
(push (progn (princ "1") 'ref-1)
(car (progn (princ "2") ref2)))) @EV "12"
@endlisp
@lisp
(let (x)
(push (setq x (list 'a))
(car (setq x (list 'b))))
x) @EV (((a) . b))
@endlisp
{\function push} first evalutes {\tt (setq x (list 'a)) @EV\ (a)},
then evaluates {\tt (setq x (list 'b)) @EV\ (b)},
then modifies the {\word car} of this latest value to be {\tt ((a) . b)}.
\endissue{PUSH-EVALUATION-ORDER}
%% 7.2.0 31
For example, in
{\tt (setf {\arg reference} {\arg value})}
{\arg value}
must be evaluated after all the subforms of {\arg reference} because
{\arg value} appears to the right of them.
%% 7.2.0 32
The expansion of these {\word operators} must consist of code that follows these
rules or has the same effect as such code. This is accomplished by
introducing temporary variables bound to the
\issue{PUSH-EVALUATION-ORDER}
subforms of the macro call.
\endissue{PUSH-EVALUATION-ORDER}
As an optimization in the implementation,
temporary variables may be eliminated whenever it
can be proven that removing them has no effect on the semantics of the program.
For example, a constant need never be saved in a temporary variable.
A variable or any {\word form} that does not have side effects need not be
saved in a temporary variable if it can be proven that its value will
not change within the scope of the generalized reference.
%% 7.2.0 57
A {\function setf\/} method may be derived from any
generalized reference.
A {\function setf\/} method
describes how to store into that generalized reference and which subforms of
the macro call are evaluated.
%% 7.2.0 59
Given knowledge of the subforms of the macro call,
it is possible to avoid evaluating
them multiple times or in the wrong
order. A {\function setf\/}
method for a given access form can be expressed as
five values:
%% 7.2.0 60
\beginlist
%% 7.2.0 64
\itemitem{\bf List of temporary variables}
The temporary variables
will be bound to the {\word values} of
the value forms sequentially as if by @Specref[let*]\rm.
\itemitem{\bf List of value forms}
The values of the value forms (these are subforms of the access form)
are bound to the temporary variables.
%% 7.2.0 61
%% 7.2.0 65
\itemitem{\bf List of store variables}
The store variables (these are temporary variables)
are to be bound to the values of the generalized reference form,
that is, the values to be
stored into the variable.
%% 7.2.0 62
\itemitem{\bf Storing form}
The storing form modifies the value of the
generalized reference and guarantees to return the value of the
store variable as
its value; these are the correct values for {\function setf\/} to
return.
The storing form may contain references to the temporary and store variables.
%% 7.2.0 63
\itemitem{\bf Accessing form}
The accessing form returns the value of the
generalized reference.
It may contain references to the temporary variables.
\endlist
%% 7.2.0 66
The value returned by the accessing form is
affected by execution of the storing form, but either of these
forms may be evaluated any number of times.
%% 7.2.0 67
The temporary variables and the store variables are generated names,
as if by @Funref[gensym] or @Funref[gentemp]\rm.
It is possible
to do more than one {\function setf\/} in parallel via
{\function psetf\/}, {\function shiftf\/}, and {\function rotatef\/}.
Computation
of the {\function setf\/}
method must always create new variable names; it may not return
the same ones every time.
Examples of the contents of the constituents of {\function setf\/} methods
follow.
%% 7.2.0 69
For a variable {\arg x}:
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt () }&; list of temporary variables \cr
{\tt () }&; list of value forms \cr
{\tt (g0001) }&; list of store variables \cr
{\tt (setq {\arg x} g0001) }&; storing form \cr
{\arg x }&; accessing form \cr
\noalign{\vskip -9pt}
}}
\caption{Examples of setf methods - 1}
\endfig
%% 7.2.0 70
For {\tt (car {\arg exp})}:
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt (g0002) }&; list of temporary variables \cr
{\tt ({\arg exp}) }&; list of value forms \cr
{\tt (g0003) }&; list of store variables \cr
{\tt (progn (rplaca g0002 g0003) g0003) }& ; storing form \cr
{\tt (car g0002) }&; accessing form \cr
\noalign{\vskip -9pt}
}}
\caption{Examples of setf methods - 2}
\endfig
%% 7.2.0 71
For {\tt (subseq {\arg seq s e})}:
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt (g0004 g0005 g0006) }&; list of temporary variables \cr
{\tt ({\arg seq s e}) }& ; list of value forms \cr
{\tt (g0007) }& ; list of store variables \cr
{\tt (progn (replace g0004 g0007 :start1 g0005 :end1 g0006) }& \cr
{\tt g0007) }& ; storing form \cr
{\tt (subseq g0004 g0005 g0006) }&{\tt ; accessing form} \cr
\noalign{\vskip -9pt}
}}
\caption{Examples of setf methods - 3}
\endfig
∂01-Mar-89 1305 X3J13-mailer Section 1.7
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Mar 89 13:04:43 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Wed, 1 Mar 89 16:00:20 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 1 Mar 89 15:58:25 EST
Date: Wed, 1 Mar 89 16:01 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Section 1.7
To: chapman%aitg.DEC@decwrl.dec.com
Cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8903011907.AA00298@decwrl.dec.com>
Message-Id: <19890301210123.2.BARMAR@OCCAM.THINK.COM>
Date: 1 Mar 89 07:23
From: chapman%aitg.DEC@decwrl.dec.com
A language extension is
any implementation-supplied {\word tool} that isn't explicitly defined
in this standard.
I don't like this definition. I suggest:
A language extension is any documented implementation-defined behavior
of a tool defined in this standard that varies from the behavior
described in this standard; or a documented consequence in a situation
that the standard defines as undefined, unspecified, or extendable by
the implementation.
This accomplishes several things:
- It restricts the definition to tools described in the standard.
Implementations are expected to provide their own tools in their own
packages, and I don't think these are considered extensions (this would
require an implementation to litter its documentation with "this is an
extension to Common Lisp" on nearly every page).
- It only talks about "behavior". Because of a cleanup issue voted on
in Hawaii, we already have specified that implementations are not
permitted to add tools with names in the standard-defined packages.
Because I don't think we want to consider tools in other packages as
extensions, the only thing left is the behavior of standard-defined
tools.
- It only refers to "documented" behavior. If the implementation varies
from the standard in an undocumented way it is a bug, not an extension.
And if the situation has an undocumented consequence in an undefined,
unspecified, or extendable situation, it is not an extension, it is just
an accident of the implementation.
barmar
∂01-Mar-89 1257 X3J13-mailer cs proposal and straw vote
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:53:49 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA20108; Wed, 1 Mar 89 15:51:57 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA11442; Wed, 1 Mar 89 15:50:01 EST
Message-Id: <8903012050.AA11442@mist.>
To: baggins@ibm.com
Cc: x3j13@sail.stanford.edu
Subject: cs proposal and straw vote
Date: Wed, 01 Mar 89 15:49:59 EST
From: Dan L. Pierson <pierson@mist.encore.com>
General comments first.
I find the layout of the proposal, mainly Appendix A, confusing to the
point of uselessness. As I understand it, chapters 1 and 2 are
intended to be a general overview of the proposal, but the detailed
changes in Appendix A are what we are effectively voting on.
Unfortunately, I can't understand Appendix A without spending a long
time destroying a copy of CLtL per draft. All of the other committees
(and X3J13 as a whole) have accepted that we are writing a new
document, not rewriting Guy's book. Why do you insist on only doing
the later?
Before the Hawaii meeting, I was willing to reluctantly ignore all of
the above and just trust the Character Committee to see that Appendix
A accurately reflected the contents of chapters 1 and 2. The
combination of the revelation of deep disagreements within the
committee, and my own attempts to answer some questions by refering to
Appendix A have forced me to change my mind. I find that I cannot
understand the proposal as presented and thus cannot vote for the
contents of Appendix A. The straw ballot that follows represents my
willingness to vote for the specific issues as described in chapters 1
and 2 of the proposal provided that such a vote does not require
acceptance of the specific wording of Appendix A.
As an example of the above problems. I was unable to find anywhere in
the latest draft either the data types of character labels and
registry names or the predicates to be used to compare them. Your
replies to comments on the January draft state that these are symbols,
which seems correct, but the proposal does not appear to specify this.
Character Registries:
While the idea of character registries doesn't sound bad in principle,
I'm still not convinced that tying the first Common Lisp standard to
the output of an ISO committee which has not been (and may never be)
formed is wise. If nothing else, this approach would appear to
guarantee a period of major incompatibility for the users of any
Common Lisp implementation which provided its own set of character
registries in advance of an ISO standard.
By the way, I find the support of the ISO Prolog committee, which
seems to be being ignored by all major US and many international
Prolog implementors, rather meaningless. If you could get support from
a major, effective ISO language committee or two I might be convinced.
Moon is correct that it is (barely) possible to enumerate all the
characters in a registry without additional functionality. Never the
less, the method he proposes is far from desirable. Since I believe
that adding non-enumerable data types to Common Lisp is a bad thing, I
sould be much happier if a registry iterator were added. The following
would suffice; I'm sure that there are many acceptable alternatives:
(DO-ALL-CHARACTERS (char registry) [Macro]
body)
In particular, I would point out that requiring the available
characters to be documented is sufficient only for some users of
commercial implementations. Students, users of non-commercial
implementations, and an unfortunate number of business users have to
get by with little or no access to printed documentation.
Specific comments:
Page 8: paragraph 2 <The proposed ISO...>
Is this meant to be a proposal from X3J13 to the not-yet-existent ISO
working group? X3J13 certainly can't make a pronouncement about the
contents of a unwritten ISO Character Registry Standard.
Page 8: paragraph 3
In other words, implementations can subset character registries but
not expand them?
Straw Ballot:
Issue: CHAR-FONT-UNUSED-CHAR-BITS-NONPORTABLE
Problem: CHAR-FONT isn't used, CHAR-BITS isn't portable.
Proposal:
Eliminate of font and bit attributes.
Add rules for an implementation supporting attributes.
The only reference I can find to implementation defined attributes is
footnote 3 at the bottom of page 6. Either the "rules" mentioned
above should be added to the proposal or this part of the issue should
be dropped.
Redefine STRING-CHAR as implementation defined.
Remove CHAR-FONT-LIMIT
Remove CHAR-BITS-LIMIT
Remove INT-CHAR
Remove CHAR-BITS
Remove CHAR-FONT
Remove MAKE-CHAR
Remove CHAR-CONTROL-BIT
Remove CHAR-META-BIT
Remove CHAR-SUPER-BIT
Remove CHAR-HYPER-BIT
Remove CHAR-BIT
Remove SET-CHAR-BIT
IF: see above
Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
Problem: CHAR-INT behavior is CHAR-CODE unless implementation
defined attributes are supported.
Proposal:
Remove CHAR-INT
IF: Moon agrees that this is sufficient for hashing (or I'm convinced that
he's wrong :-)).
Issue: CHARACTER-TYPE-RESTRICTIVEC
Problem: CHARACTER type doesn't allow thin & fat characters.
Proposal:
Define BASE-CHARACTER as a subtype of STRING.
Standard characters are a subset of the base
characters.
STANDARD-CHAR type is replaced by (CHARACTER :STANDARD)
Remove the semi-standard characters.
YES
Issue: STRING-TYPE-RESTRICTIVE
Problem: STRING type doesn't allow thin & fat strings.
Proposal:
Define STRING as a union type
STRING used as a type specifier for object creation
means (VECTOR CHARACTER)
All string functions operate as specified on any
string object except it is an error to insert
an extended character into a base string.
What do STRING-LESSP, etc. mean for non-standard-character strings?
Extend the COERCE function to allow coercion from
base string to extended string.
IF: the above is resolved, possibly by explictly saying it's undefined.
Issue: STRING-TYPE-ABBREVIATIONS
Problem: new types are awkward to name, want abbreviations.
Proposal:
Add BASE-STRING
Add GENERAL-STRING
YES
Issue: SIMPLE-STRING-TYPE-RESTRICTIVE
Problem: SIMPLE STRING type doesn't allow thin & fat strings.
Proposal:
Define SIMPLE-STRING as a union type
Define SIMPLE-STRING as a type specifier for object
creation means (SIMPLE-ARRAY CHARACTER (size))
YES
Issue: SIMPLE-STRING-TYPE-ABBREVIATIONS
Problem: new types are awkward to name, want abbreviations.
Proposal:
Add SIMPLE-BASE-STRING
Add SIMPLE-GENERAL-STRING
YES
Issue: FILE-EXTERNAL-REPRESENTATION
Problem: can't specify external encoding even when there are lots
Proposal:
Add :EXTERNAL-CODED-CHARACTER-FORMAT keyword to OPEN
YES
Issue: STRING-BINARY-WIDTH
Problem: Can't find out how many bytes a string will take when
written as text
Proposal:
Add :EXTERNAL-CODED-STRING-LENGTH function
YES
I think that reference to "terminal screen templates" has confused
some people without adding to the content.
Issue: CHAR-CODE-NON-PORTABLE
Problem: no way to talk about well-known external coding methods, only
internal codes
Proposal:
Add CHAR-CCS-VALUE function
YES
Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
Problem: Can't portably talk about non-standard characters
Proposal:
Introduce the concept of Registries
Standardize on #\registry:id, add all-implemented-registries
Add *ALL-CHARACTER-REGISTRY-NAMES* variable
Add FIND-CHAR function
Add CHAR-LABEL function
Add CHAR-REGISTRY-NAME function
New syntax for CHARACTER type specifier
New #\label:registry character name syntax
New argument to CHARACTERP
NO: Unless the issues raised in the first part of this message are resolved.
∂01-Mar-89 1335 X3J13-mailer Re: Section 1.7
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 13:35:17 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA20628; Wed, 1 Mar 89 16:31:49 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA11532; Wed, 1 Mar 89 16:29:55 EST
Message-Id: <8903012129.AA11532@mist.>
To: Barry Margolin <barmar@Think.COM>
Cc: "chapman%aitg.DEC@decwrl.dec.com"@Multimax.encore.com,
x3j13@sail.stanford.edu,
"skona%csilvax@hub.ucsb.edu"@multimax.encore.com
Subject: Re: Section 1.7
In-Reply-To: Your message of Wed, 01 Mar 89 16:01:00 -0500.
<19890301210123.2.BARMAR@OCCAM.THINK.COM>
Date: Wed, 01 Mar 89 16:29:54 EST
From: Dan L. Pierson <pierson@mist.encore.com>
- It restricts the definition to tools described in the standard.
Implementations are expected to provide their own tools in their own
packages, and I don't think these are considered extensions (this would
require an implementation to litter its documentation with "this is an
extension to Common Lisp" on nearly every page).
I'm not sure I agree with you here. Lucid certainly documents every
new "tool" as "a Lucid extension to Common Lisp" and this doesn't seem
to unduely clutter their documentation.
∂01-Mar-89 1526 X3J13-mailer minor comments on letter ballot material
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Mar 89 15:26:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 548782; Wed 1-Mar-89 18:22:47 EST
Date: Wed, 1 Mar 89 18:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: minor comments on letter ballot material
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@SAIL.STANFORD.EDU, skona%csilvax@hub.ucsb.edu
Message-ID: <19890301232245.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here are some minor comments about the material that you mailed out
with your letter ballot. This is not an official response to the
letter ballot.
I like the terms in the error-terminology proposal, however the
meanings of the terms are rather sloppily written. To take one
example, for "the consequences are unspecified", it says that
implementations are permitted to specify the consequences. However,
for "the consequences are undefined", it neither says that
implementations are permitted to specify the consequences, nor
that they are not. I noticed a few other things that might be
inconsistencies or ambiguities in these descriptions. I also
noticed that the reference sections in the letter ballot do not
actually use this error terminology, for the most part. I assume
these deficiencies are just due to the schedule, and will be
corrected before the final draft. I would certainly recommend
putting a lot of time into the exact wording of the definitions
of the error terminology, since that will have high leverage for
the understanding of the rest of the specification. CLtL suffered
greatly because we did not do this. I don't think it's effective
for the committee of the whole to argue over that exact wording,
I think it would be more appropriate for 2 or 3 people on the
editorial committee to write the whole set of descriptions at
one time in a consistent and unambiguous style. (On the subject
of implementations specifying the consequences, I see no advantage
to the standard forbidding implementations to say anything about
what the particular implementation will do in situations that
conforming programs are forbidden to depend upon.)
On page 2-12 of section 2.3, the second to last paragraph came from
something in 88-002R that said that CLtL doesn't specify some class
orderings but CLOS does. Now that CLtL and CLOS are not two separate
standards, this no longer makes sense. You don't need to talk about
classes being layered on top of a preexisting type system defined by
somebody else. Possibly you should delete all but the first sentence of
this paragraph.
The table of built-in classes on page 2-13 is missing a great many
entries. Now that cleanup issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED has
passed, the types HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, and
RANDOM-STATE should be added to this table. I also believe that the
passage of FUNCTION-TYPE means that FUNCTION should be added to this
table, although I'm less confident there. Each one of these classes
has a CPL consisting of just itself and T. Do you need a separate
cleanup issue to be passed to do this?
Page 2-24 says implementations are permitted to make certain
optimizations, but does not say what they are. This paragraph
came from page 1-42 of 88-002R, which did say (or pointed to
where it is said.) Note: I have not done a line by line
comparison of this document with 88-002R and I have no intention
of doing so. This is just a discrepancy that jumped out at me.
Page 2-9 says "Updating an instance does not change its identity as
defined by the EQ function". Page 2-24 does not say "Changing the class
of an instance does not change its identity as defined by the EQ
function". My belief is that it was the intent of the CLOS committee to
say that, although 88-002R fails to say it. Do you need a separate
cleanup issue to be passed to fix this?
Here's a suggestion from one of our CLOS implementors. Would this
change (adding the word "affected") require a vote?
Page 2-9 Redefining Classes
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time a slot of that instance is read or written.
I think I'd prefer if this said:
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time an affected slot of that instance is
read or written.
I (Moon again) think this is a good idea.
∂01-Mar-89 1853 X3J13-mailer Re: minor comments on letter ballot material
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Mar 89 18:53:24 PST
Received: from Semillon.ms by ArpaGateway.ms ; 01 MAR 89 18:46:12 PST
Date: Wed, 1 Mar 89 18:45 PST
From: Gregor.pa@Xerox.COM
Subject: Re: minor comments on letter ballot material
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@SAIL.STANFORD.EDU,
skona%csilvax@hub.ucsb.edu
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <19890301232245.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890302024559.5.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
Date: Wed, 1 Mar 89 18:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Here's a suggestion from one of our CLOS implementors. Would this
change (adding the word "affected") require a vote?
Page 2-9 Redefining Classes
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time a slot of that instance is read or written.
I think I'd prefer if this said:
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time an affected slot of that instance is
read or written.
I (Moon again) think this is a good idea.
This change makes is impossible for people to use MAKE-INSTANCES-OBSOLETE
to arrange for any future access to the slots of an instance to trap.
One of the reasons we gave for not adding an instance enumeration
mechanism was the availability of this functionality. So, I don't think
we should make this change.
I agree that the other change you suggested (change-class vs. eq) is in
line with our original intent and we should go ahead and make it. I
hope it doesn't require a vote.
Page 2-9 says "Updating an instance does not change its identity as
defined by the EQ function". Page 2-24 does not say "Changing the class
of an instance does not change its identity as defined by the EQ
function". My belief is that it was the intent of the CLOS committee to
say that, although 88-002R fails to say it. Do you need a separate
cleanup issue to be passed to fix this?
-------
∂01-Mar-89 2340 X3J13-mailer Section 2.2, part 1
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 23:38:50 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA07792; Wed, 1 Mar 89 23:36:51 PST
Message-Id: <8903020736.AA07792@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA07792; Wed, 1 Mar 89 23:36:51 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Mar 89 02:32
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.2, part 1
%% Types - part 1
%% Type Hierarchy and Relationships
\beginsubSection{Type Hierarchy and Relationships}
Figure {\chapno--\the\capno}
depicts the @clisp\ type hierarchy and relationships.
An explanation of the
relationships of data types to each other follows.
\beginlist
%% 2.15.0 4
\itemitem{\bull} {\datatype t} is a {\word supertype} of every type whatsoever.
Every {\word object} is of type {\datatype t}.
%% 2.15.0 5
\itemitem{\bull} {\datatype Nil} is a {\word subtype} of every type whatsoever.
No {\word object} is of type {\datatype nil}.
\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
The following will be left out of the standard.
%% 2.15.0 6
\itemitem{\bull} {\datatype Cons}, {\datatype symbol},
{\datatype array}, {\datatype number}, and {\datatype character}
are pairwise {\word disjoint}.
\endissue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
%% 2.15.0 7
\itemitem{\bull} {\datatype Rational}, {\datatype float}, and {\datatype complex}
are pairwise {\word disjoint}
{\word subtypes} of {\datatype number}.
%% 2.15.0 8
\itemitem{\bull} {\datatype Integer}
and {\datatype ratio} are {\word disjoint subtypes }
of {\datatype rational}.
%% 2.15.0 10
\itemitem{\bull}
{\datatype Fixnum} and {\datatype bignum}
are {\word disjoint} {\word subtypes} of {\datatype integer}.
%% 2.15.0 12
\itemitem{\bull}
{\datatype Short-float}, {\datatype single-float}, {\datatype double-float}, and
{\datatype long-float} are {\word subtypes} of {\datatype float}.
Any two of them must be
either {\word disjoint} or identical;
if identical, then any other types between
them in the above ordering must also be identical to them
(for example, if {\datatype single-float} and {\datatype long-float}
are identical,
then {\datatype double-float} must be identical to them also).
%% 2.15.0 13
\itemitem{\bull} {\datatype Null} is a
{\word subtype} of {\datatype symbol}; the only {\word object} of
type
{\datatype null} is @nil\rm.
%% 2.15.0 14
\itemitem{\bull} {\datatype Cons} and {\datatype null}
form an {\word exhaustive partition} of
{\datatype list}.
%% 2.15.0 15
\itemitem{\bull} {\datatype Standard-char} is a {\word subtype}
of {\datatype string-char};
{\datatype string-char} is a {\word subtype} of {\datatype character}.
%% 2.15.0 16
\itemitem{\bull} {\datatype String} is a
{\word subtype} of {\datatype vector}.
{\datatype String}
is identical to {\tt (vector string-char)}, which in turn
is the same as {\tt (array string-char (*))}.
%% 2.15.0 17
\itemitem{\bull} {\datatype Bit-vector}
is a {\word subtype} of {\datatype vector}, for {\datatype bit-vector}
means {\tt (vector bit)}.
%% 2.15.0 18
\itemitem{\bull} {\tt (vector t)} and
{\datatype string}, and {\datatype bit-vector} are {\word disjoint}.
%% 2.15.0 19
\itemitem{\bull} {\datatype Vector} is a
{\word subtype} of {\datatype array};
for all types @f[x]\rm,
{\tt (vector x)} is the same as
{\tt (array x (*)).}
%% 2.15.0 20
\itemitem{\bull} {\datatype Simple-array} is a {\word subtype}
of {\datatype array}.
%% 2.15.0 21
\itemitem{\bull} {\datatype Simple-vector}, {\datatype simple-string}, and
{\datatype simple-bit-vector} are
{\word disjoint subtypes} of {\datatype simple-array}, for they
respectively mean
{\tt (simple-array t (*))}, {\tt (simple-array string-char (*))},
and {\tt (simple-array bit (*))}.
%% 2.15.0 22
\itemitem{\bull} {\datatype Simple-vector} is a {\word subtype}
of {\datatype vector},
and is
a {\word subtype} of {\tt (vector t)}.
%% 2.15.0 23
\itemitem{\bull} {\datatype Simple-string} is a
{\word subtype} of {\datatype string}.
%% 2.15.0 25
\itemitem{\bull} {\datatype Simple-bit-vector}
is a {\word subtype} of {\datatype bit-vector}.
%% 2.15.0 26
\itemitem{\bull} {\datatype Vector} and {\datatype list}
are {\word disjoint subtypes} of {\datatype sequence}.
\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
The following will be left out of the standard.
%% 2.15.0 27
\itemitem{\bull} {\datatype Hash-table}, {\datatype readtable},
{\datatype package}, {\datatype pathname},
{\datatype stream}, and {\datatype random-state} are {\word pairwise disjoint}.
\endissue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
\itemitem{\bull} The types {\datatype cons},
{\datatype symbol}, {\datatype array},
{\datatype number}, {\datatype character}, {\datatype hash-table},
\issue{FUNCTION-TYPE:X3J13-MARCH-88}
{\datatype function},
\endissue{FUNCTION-TYPE:X3J13-MARCH-88}
{\datatype readtable},
{\datatype package}, {\datatype pathname}, {\datatype stream},
{\datatype random-state}, and any single other type created
by {\function defstruct} or {\function defclass} are pairwise disjoint.
\endissue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
%% 2.15.0 28
\itemitem{\bull} Any two types created by @Macref[defstruct] are {\word disjoint} unless
one is a {\word supertype} of the other by virtue of
the {\function defstruct} {\keyword :include} option.
\itemitem{\bull} Any two classes created by {\function defclass} are disjiont
unless one is a superclass of the other.
%% 2.15.0 29
\itemitem{\bull} An {\word exhaustive union} for {\datatype common} is formed by
{\datatype cons}, {\datatype symbol}, {\tt (array x)} where @f[x]
is either {\datatype t} or
a {\word subtype}
of {\datatype common}, {\datatype string}, {\datatype fixnum}, {\datatype
bignum}, {\datatype ratio},
{\datatype short-float}, {\datatype single-float}, {\datatype double-float},
{\datatype long-float},
{\tt (complex x)} where @f[x] is a
{\word subtype} of {\datatype common},
{\datatype standard-char}, {\datatype hash-table}, {\datatype readtable},
{\datatype package}, {\datatype pathname},
{\datatype stream}, {\datatype random-state}, and all types
created by the user
via @Macref[defstruct]\rm.
An implementation may not add {\word subtypes} to
{\datatype common}.
\endlist
%%kc2
\eject
\fig{
\def\IgnoreLineBreaks{\catcode'15=9 \catcode'12=9}
\def\IgnoreWhiteSpace{\catcode'11=9 \catcode'40=9 \IgnoreLineBreaks}
\def\DontIgnoreWhiteSpace{\catcode'12=\active\catcode'15=5\catcode'11=10\catcode'40=10}
\font \pipefont= circle10
\font \foofont = amr10 at 1sp
\IgnoreWhiteSpace
\let \adv=\advance
\def\he{height}
\def\wi{width}
\def\de{depth}
\newdimen \stroke
\stroke= \fontdimen8\pipefont % thickness of line in circles
\newdimen \radius \radius=6pt % radius of circles
\newdimen\irad \irad=\radius\advance\irad by -.5\stroke
\newdimen\orad \orad=\radius\advance\irad by .5\stroke
\newbox\BStrutbox
\setbox\BStrutbox\hbox{\vrule\wi0pt\he10pt\de10pt}
\def\BoxStrut{\unhcopy\BStrutbox}
!% Arrows
\newdimen\ArrowShift
\ArrowShift=\fontdimen22\tensy
\advance\ArrowShift by -0.5\stroke
\def\StrikeOut #1
{ \setbox0\hbox{#1}
\hbox to 1\wd0
{ \vrule \he\stroke\de0pt\wi\wd0
\hskip-\wd0
\unhbox0
}
}
\def\LeftArrow
{ \hskip 0.5\stroke
\StrikeOut{\lower\ArrowShift\hbox to 10pt{\tensy\char'40\hss}}
}
\def\RightArrow
{ \StrikeOut{\lower\ArrowShift\hbox to 10pt{\hss\tensy\char'41}}
\hskip 0.5\stroke
}
\def\ArrowLine
{ \StrikeOut{\hskip 10pt\hskip 0.5\stroke}
}
\def\LeftToRight
{ \let\RightSideArrow=\ArrowLine
\let\LeftSideArrow=\RightArrow
}
\def\RightToLeft
{ \let\LeftSideArrow=\ArrowLine
\let\RightSideArrow=\LeftArrow
}
\def\NoArrows
{ \let\LeftSideArrow=\ArrowLine
\let\RightSideArrow=\ArrowLine
}
!% boxes around tokens
\let\NonterminalFont=\tenrm
\newbox\TStrutbox
\setbox0\hbox{\NonterminalFont{Bg}}
\setbox\TStrutbox\hbox{\vrule\wi0pt\he\ht0\de\dp0}
\def\TextStrut{\unhcopy\TStrutbox}
\def\HorzLine{\hrule \he \stroke \de 0pt}
\def\HFil{\leaders\HorzLine\hfil}
\def\HFill{\leaders\HorzLine\hfill}
\def\Nonterminal#1
{\setbox1\vbox to 0pt{
\vss
\hbox{\TextStrut\NonterminalFont\space#1\space\hskip-\stroke}
\vss}
\hbox{
\BoxStrut
\LeftSideArrow
\lower\irad\vbox{
\TopSquare
\copy1
\BotSquare}
\RightSideArrow}
}
\def\TopSquare
{ \hbox{
\vrule\he\stroke\de\irad\wi\stroke
\vrule\he\stroke\de0pt\wi\wd1
\vrule\he\stroke\de\irad\wi\stroke}
}
\def\BotSquare
{ \hbox{
\vrule\he\orad\de0pt\wi\stroke
\vrule\he\stroke\de0pt\wi\wd1
\vrule\he\orad\de0pt\wi\stroke}
}
\def\\#1{\Nonterminal{#1}\HFil}
\def\last#1{{\def\RightSideArrow{}\Nonterminal{#1}}}
!% piping
\def\foo{\rlap{\foofont\char'40}}
\def\FulVert{\vrule \wi\stroke\foo\hskip-\stroke}
\def\TopVert{\vrule\de-\irad \wi\stroke\foo\hskip-\stroke}
\def\BotVert{\vrule\he-\orad \wi\stroke\foo\hskip-\stroke}
\def\Center#1,#2.
{\hskip\radius\foo#1\lower.5\stroke\hbox{\pipefont#2}\hskip\radius}
\def\ru{\char'10\hskip -2\radius}
\def\rd{\char'11\hskip -2\radius}
\def\ld{\char'12\hskip -2\radius}
\def\lu{\char'13\hskip -2\radius}
\def\thru{\hskip-\radius\vrule\he\stroke\de0pt\wi2\radius\hskip\radius\hskip-2\radius}
\def\Center#1,#2.
{\foo\hskip\radius#1{\pipefont#2\unskip}\hskip-\radius}
\def\LT{\Center\BotVert,\lu.}
\def\LU{\Center\FulVert,\lu.}
\def\LL{\Center\FulVert,\ld.}
\def\LB{\Center\TopVert,\ld.}
\def\LMid{\Center\TopVert\BotVert,\rd\ru\thru.}
\def\LMU{\Center\TopVert,\rd\thru.}
\def\LML{\Center\BotVert,\ru\thru.}
\def\LFD{\Center\FulVert,\ru\thru.}
\def\LS{\Center\TopVert\BotVert,\rd\ru.}
\def\RT{\Center\BotVert,\ru.}
\def\RU{\Center\FulVert,\ru.}
\def\RL{\Center\FulVert,\rd.}
\def\RB{\Center\TopVert,\rd.}
\def\RMid{\Center\TopVert\BotVert,\ld\lu\thru.}
\def\RMU{\Center\TopVert,\ld\thru.}
\def\RML{\Center\BotVert,\lu\thru.}
\def\Cross{\Center\FulVert,\thru.}
\def\LR{\Center,\thru.}
\def\TB{\Center\FulVert,.}
!% ShiftBox
\newbox\x
\newbox\y
\newbox\tempy
\newbox\z
\newbox\tempz
\def\ShiftBox#1{
\savemod
\saverulebox
\setbox\x
\vbox{ \everycr{\noalign{{\modifyrulebox\global\setbox\z\hbox{}}}}
\halign{&\setbox\x\hbox{##}
\global \setbox\z\hbox{\unhbox\z\vrule\he\ht\x\de\dp\x\wi0pt}
\unhbox\x
\cr
#1}}%
\lower\ht\y\box\x\HFil
\restoremod
\restorerulebox
}
\def\saverulebox{
\setbox\tempy\box\y
\global \setbox\y\vbox{}
\setbox\tempz\box\z
\global \setbox\z\hbox{}
}
\def\restorerulebox{
\global \setbox\y\box\tempy
\global \setbox\z\box\tempz
}
\def\topmod{}
\def\thisrow{\global\let\modifyrulebox\firstmod}
\def\firstmod{
\global\setbox\y\vbox{\hrule\he0pt\wi0pt\de\dp\z}
\global\let\modifyrulebox\latermod
}
\def\latermod{
\global\setbox\y\vbox{\unvbox\y\hrule\he\ht\z\de\dp\z\wi0pt}
}
\def\savemod{
\let\tempmod\modifyrulebox
\global \let\modifyrulebox\topmod
}
\def\restoremod{
\global\let\modifyrulebox\tempmod
}
\DontIgnoreWhiteSpace
!{\baselineskip0pt
\lineskip0pt
\LeftToRight
\IgnoreWhiteSpace
\def\ms{\os
\os\os\os}
\def\os{\omit\span}
\hbox{
\\{nil}
\ShiftBox{
\ms\ShiftBox{
\ShiftBox{
\ShiftBox{
\LT\\{fixnum}&\RT\cr
\LU\\{bignum}&\RMU\thisrow\cr
}\\{integer}&\RML\thisrow\cr
\LU\\{ratio}&\RB\cr
}\\{rational}&\RT\cr
\ShiftBox{
\LU\\{short-float}&\RT\cr
\LU\\{single-float}&\RMid\thisrow\cr
\LU\\{double-float}&\RL\cr
\LU\\{long-float}&\RB\cr
}\\{float}&\RMid\thisrow\cr
\LU\\{complex}&\RB\cr
}\\{number}&\RT\cr
\ms\LU\\{standard-char}\\{string-char}\\{character}&\RU\cr
\LU\\{null}&\os\os\os\LML\\{symbol}&\RU\cr
\LMid\\{cons}&\os\os\RMU\\{list}&\RML\\{sequence}&\RMid\thisrow\cr
\os\LL\\{simple-vector}&\LML\HFil&\RML\\{vector}&\LS&\TB\cr
\os\LL\\{simple-bit-vector}&\LFD\\{bit-vector}&\RL&\TB&\TB\cr
\os\LL\\{simple-string}&\LFD\\{string}&\RB&\TB&\TB\cr
\os\TB&\os\LB\HFil\\{simple-array}&\RMU\\{array}&\RL\cr
\ms\LL\\{function}\\{compiled-function}&\RL\cr
\ms\LL\\{stream}&\RL\cr
\ms\LL\\{hash-table}&\RL\cr
\ms\LL\\{readtable}&\RL\cr
\ms\LL\\{package}&\RL\cr
\ms\LL\\{pathname}&\RL\cr
\ms\LL\\{random-state}&\RL\cr
\ms\LB\\{structures}&\RB\cr
}
\last{t}}}
}\caption{Relationships among the Common Lisp data types}
\endfig
\eject
%%kc1
\endsubSection%{Type Hierarchy and Relationships}
\beginsubSection{Data Type Definition}
Following is a description of each @clisp\ {\word type}.
%% 2.0.0 6
\beginsubsubsection{\datatype t}
The set of all {\word objects} is specified
by @true\rm.
\beginsubsubsection{\datatype Number}
The type {\datatype number\/} is composed of the pairwise {\word disjoint}
{\datatype rational}, {\datatype float}, and {\datatype complex\/} subtypes\/.
An {\word object} of type {\datatype number\/} is called a {\datatype
number\/}.
%% 12.0.0 4
Two {\datatype numbers\/} that are {\function eql} or
{\function =} are not necessarily {\function eq}.
The contagion rules for implicit coercions of arguments in
{\word operations} follow:
\beginlist
\itemitem{\bull}
When a {\word shorter}
{\datatype floating-point} number is combined with a longer one in an
operation,
the result will be of the {\word type} of the longer
of the two {\datatype floating-point} numbers.
\issue{CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE)}
\itemitem{\bull}
For {\word functions} that combine arguments of different {\word types},
when one argument is a {\datatype rational} and the other is
a {\datatype floating-point} number,
the {\datatype rational} is first
converted to a {\datatype floating-point} number of
the same format.
For {\word functions} that compare arguments of different {\word types},
when one argument is a {\datatype rational} and the other is
a {\datatype floating-point} number, the function
{\function rational} is effectively
called to convert the {\datatype floating-point}
number to a {\datatype rational} and then an exact
comparison is performed. In the case of {\datatype complex\/}
numbers, the real and
imaginary parts are handled individually.
\endissue{CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE)}
\itemitem{\bull}
When a non-{\datatype complex\/}
number meets a {\datatype complex\/} number, the non-{\datatype complex\/}
number is in effect first converted to a
{\datatype complex\/} number by providing an
imaginary part of {\tt $0$}.
\endlist
%% 12.5.3 1
Many of the irrational and transcendental functions are multiply defined
in the complex domain; for example, there are in general an infinite
number of complex values for the logarithm function. In each such
case, a principal value must be chosen for the function to return.
In general, such values cannot be chosen so as to make the range
continuous; lines in the domain
called branch cuts must be defined, which in turn
define the discontinuities in the range.
%% 12.5.3 2
@clisp\ defines the branch cuts, principal values, and boundary
conditions for the complex functions following
@apl\rm.
%% 12.7.0 1
%% 12.7.0 2
Logical operations require {\datatype integers}
as arguments; an error of type {\datatype type-error}
is signalled if a non-{\datatype integer} is supplied
as an argument.
{\datatype Integer} arguments to logical operations are treated as if
they were represented in two's-complement notation.
Internally an implementation
may or may not use a two's-complement representation.
%% 12.8.0 2
The byte-manipulation {\word forms}
use {\word objects} called byte specifiers to
designate a specific byte position within an {\datatype integer}.
The representation of a byte specifier is implementation-dependent ---
it may or may not be a {\datatype number}.
The function {\function byte} will construct a byte specifier,
and the byte-manipulation {\word forms} will accept it.
The following figures contain lists of {\word tools} applicable to
{\datatype numbers}.
Figure {\chapno--\the\capno} lists the number predicate and comparison
{\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt zerop }&{\tt plusp }&{\tt minusp }\cr
{\tt oddp }&{\tt evenp } &{\tt = }\cr
{\tt /= }&{\tt < } &{\tt > }\cr
{\tt <= }&{\tt >= } &{\tt max }\cr
{\tt min} & & \cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the {\word tools} for arithmetic operations.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt + }&{\tt - } &{\tt * }\cr
{\tt / }&{\tt 1+ } &{\tt 1- }\cr
{\tt incf }&{\tt decf } &{\tt conjugate }\cr
{\tt gcd }&{\tt lcm } & \cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 2}
\endfig
Figure {\chapno--\the\capno} lists the {\word tools}
for exponential, logarithmic, and trigonometric operations.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt exp }&{\tt expt } &{\tt log }\cr
{\tt sqrt }&{\tt isqrt } &{\tt abs }\cr
{\tt phase }&{\tt signum } &{\tt sin }\cr
{\tt cos }&{\tt tan } &{\tt cis }\cr
{\tt asin }&{\tt acos } &{\tt atan }\cr
{\tt pi }&{\tt sinh } &{\tt cosh }\cr
{\tt tanh }&{\tt asinh } &{\tt acosh }\cr
{\tt atanh }& &\cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 3}
\endfig
Figure {\chapno--\the\capno} lists the {\word tools}
for type conversion and component extraction operations.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt float }&{\tt rational} &{\tt rationalize } \cr
{\tt numerator} & {\tt denominator }& {\tt floor} \cr
{\tt ceiling} & {\tt truncate} & {\tt round} \cr
{\tt mod} & {\tt rem} & {\tt ffloor}\cr
{\tt fceiling} & {\tt ftruncate} & {\tt fround}\cr
{\tt decode-float} & {\tt scale-float} & {\tt float-radix}\cr
{\tt float-sign} & {\tt float-digits} & {\tt float-precision}\cr
{\tt integer-decode-float} & {\tt complex} & {\tt realpart}\cr
{\tt imagpart} & & \cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 4}
\endfig
Figure {\chapno--\the\capno} lists the logical operation {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt logior} & {\tt logxor} & {\tt logand} \cr
{\tt logeqv} & {\tt lognand} & {\tt lognor} \cr
{\tt logandc1} & {\tt logandc2 }&{\tt logorc1 } \cr
{\tt logorc2 } & {\tt boole }&{\tt boole-clr }\cr
{\tt boole-set } & {\tt boole-1 }&{\tt boole-2 }\cr
{\tt boole-c1 } & {\tt boole-c2 }&{\tt boole-and }\cr
{\tt boole-ior } & {\tt boole-xor }&{\tt boole-eqv }\cr
{\tt boole-nand } & {\tt boole-nor }&{\tt boole-andc1 }\cr
{\tt boole-andc2 } & {\tt boole-orc1 }&{\tt boole-orc2 }\cr
{\tt lognot } & {\tt logtest }&{\tt logbitp }\cr
{\tt ash } & {\tt logcount} & {\tt integer-length }\cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 5}
\endfig
Figure {\chapno--\the\capno} lists the byte manipulation {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt byte} &{\tt byte-size} & {\tt byte-position}\cr
{\tt ldb} & {\tt ldb-test} & {\tt mask-field} \cr
{\tt dpb} & {\tt deposit-field} & \cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 6}
\endfig
Figure {\chapno--\the\capno} lists the implementation-dependent parameters.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt most-positive-fixnum }& {\tt most-negative-fixnum }\cr
{\tt most-positive-short-float } &{\tt least-positive-short-float} \cr
{\tt least-negative-short-float} & {\tt most-negative-short-float} \cr
{\tt most-positive-single-float } & {\tt least-positive-single-float} \cr
{\tt least-negative-single-float} & {\tt most-negative-single-float} \cr
{\tt most-positive-double-float} & {\tt least-positive-double-float} \cr
{\tt least-negative-double-float} & {\tt most-negative-double-float} \cr
{\tt most-positive-long-float} &{\tt least-positive-long-float} \cr
{\tt least-negative-long-float} & {\tt most-negative-long-float} \cr
{\tt short-float-epsilon} & {\tt single-float-epsilon} \cr
{\tt double-float-epsilon} & {\tt long-float-epsilon} \cr
{\tt short-float-negative-epsilon} & {\tt single-float-negative-epsilon}\cr
{\tt double-float-negative-epsilon}& {\tt long-float-negative-epsilon} \cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 7}
\endfig
\beginsubsubsection{\datatype Rational}
The type {\datatype
rational} is composed of the {\word disjoint}
{\datatype integer} and {\datatype
ratio} subtypes.
An {\word object} of type {\datatype rational\/} is called a {\datatype
rational}.
%% 12.1.0 2
The following rules apply to {\datatype rational} computations.
\beginlist
\itemitem {--} Rational computations cannot overflow in the usual sense
(though there may not be enough storage
to represent one), since
{\datatype integers} and {\datatype ratios}
may in principle be of any magnitude.
%% 2.1.2 1
\itemitem {--} The representation of a
{\datatype rational} number is as the ratio of two
integers, the numerator and denominator, where the greatest common divisor of
the numerator and denominator is one, and where the denominator is positive
and greater than one. If the value of a {\datatype rational} is
an {\datatype integer}, it is
represented as an integer.
%% 2.1.2 2
%% 12.1.0 5
\itemitem{--} If any computation produces
a result that is a {\datatype ratio} of
two {\datatype integers} such that the denominator evenly divides the
numerator, then the result is converted to the equivalent
{\datatype integer}.
%% 12.1.0 3
\itemitem{--} When
{\datatype rational} and {\datatype floating-point} numbers
are compared or combined by
a numerical {\word function},
the {\datatype rational}
is first converted to a {\datatype floating-point} number of
the same format. For {\word forms} such as {\function +}
that take more than two arguments,
it is permitted that part of the operation be carried out exactly using
{\datatype rationals}
and the rest be done using floating-point arithmetic.
%% 12.5.0 4
\itemitem{--}
When the arguments to
a mathematical
{\word function} are all {\datatype rational} and the true mathematical result
is also (mathematically) rational, then unless otherwise noted
an implementation is free to return either an accurate
{\datatype rational} result
or a {\datatype single-float} approximation.
If the arguments are all {\datatype rational}
but the result cannot be expressed
as a {\datatype rational} number, then a {\datatype single-float}
approximation is always returned.
\endlist
∂02-Mar-89 0008 X3J13-mailer Section 2.2 - part 3
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Mar 89 00:08:35 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA09450; Thu, 2 Mar 89 00:06:40 PST
Message-Id: <8903020806.AA09450@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA09450; Thu, 2 Mar 89 00:06:40 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Mar 89 03:05
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.2 - part 3
%%Types - part 3
\beginsubsubsection{\datatype Null}
The only {\word object} of type {\datatype null\/} is @nil\rm.
\beginsubsubsection{\datatype Sequence}
The type {\datatype sequence} has
{\datatype vector} and {\datatype list}
as {\word disjoint subtypes}.
An {\word object} of type {\datatype sequence\/} is called a {\datatype
sequence}.
Figure {\chapno--\the\capno} lists the {\datatype sequence} {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt elt }&{\tt subseq }&{\tt copy-seq }\cr
{\tt length }&{\tt reverse }&{\tt nreverse }\cr
{\tt make-sequence }&{\tt concatenate }&{\tt map }\cr
{\tt some }&{\tt every }&{\tt notany }\cr
{\tt notevery }&{\tt reduce }&{\tt fill }\cr
{\tt replace }&{\tt remove }&{\tt remove-if }\cr
{\tt remove-if-not }&{\tt delete }&{\tt delete-if }\cr
{\tt delete-if-not }&{\tt remove-duplicates }&{\tt delete-duplicates }\cr
{\tt substitute }&{\tt substitute-if }&{\tt substitute-if-not }\cr
{\tt nsubstitute }&{\tt nsubstitute-if }&{\tt nsubstitute-if-not }\cr
{\tt find }&{\tt find-if }&{\tt find-if-not }\cr
{\tt position }&{\tt position-if }&{\tt position-if-not }\cr
{\tt count }&{\tt count-if }&{\tt count-if-not }\cr
{\tt mismatch }&{\tt search }&{\tt sort }\cr
{\tt stable-sort }&{\tt merge }&\cr
\noalign{\vskip -9pt} }}
\caption{Sequence tools}
\endfig
%% 14.0.0 19
Whenever a {\datatype sequence} function must construct and return
a new {\datatype vector}, it always returns a {\datatype simple-vector}.
In particular, any {\datatype strings} constructed
will be {\datatype simple-strings}.
%% 2.5.1 1
\beginsubsubsection{\datatype Vector}
The type {\datatype vector} has {\word subtypes} {\datatype simple-vector,
string}, and {\datatype bit-vector}.
An {\word object} of type {\datatype vector}
(a {\datatype vector}) is a
one-dimensional {\datatype array\/}.
\beginsubsubsection{\datatype Simple-vector}
An {\word object} of type {\datatype simple-vector}
(a {\datatype simple-vector}) is
a {\datatype vector}
that is not displaced to another {\datatype vector},
has no
{\word fill pointer},
is able to hold elements of any {\word type},
and is not to have its size adjusted dynamically after
creation.
\beginsubsubsection{\datatype Bit-vector}
An {\word object} of type {\datatype bit-vector}
(a {\datatype bit-vector})
is a
{\datatype vector} composed of bits.
The type {\datatype bit-vector} has the type {\datatype simple-bit-vector}
as its {\word subtype}.
\beginsubsubsection{\datatype Simple-bit-vector}
An {\word object} of type {\datatype simple-bit-vector}
(a {\datatype simple-bit-vector}) is
a {\datatype bit-vector} that is not displaced to another
{\datatype bit-vector},
has no {\word fill pointer},
and is not to have its size adjusted dynamically after
creation.
%% 2.5.2 1
%% 18.0.0 3
\beginsubsubsection{\datatype String}
An {\word object} of type {\datatype string}
(a {\datatype string}) is
a {\datatype vector} whose
elements are {\datatype string-chars\/}.
{\datatype Simple-string} is a {\word subtype} of {\datatype string}.
Figure {\chapno--\the\capno}
lists the {\word tools} that are applicable to {\datatype strings}.
The following rules apply to {\datatype strings} and {\datatype string}
operations:
\beginlist
%% 18.0.0 7
\itemitem{--}
{\datatype Strings} may have {\word fill pointers}.
%% 18.0.0 4
\itemitem{--}
An {\word operator}
that uses the print name of an argument provided as a
{\datatype symbol} (most of
the operators in Figure {\chapno--\the\capno})
is not allowed to modify that {\datatype
symbol}.
%% 18.0.0 5
%% paragraph duplicated in descriptions of string-equal and string=
%% 18.0.0 6
%% paragraph duplicated in description of stringp
\endlist
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt char }&{\tt schar }&{\tt string= }\cr
{\tt string-equal }&{\tt string< }&{\tt string> }\cr
{\tt string<= }&{\tt string>= }&{\tt string/= }\cr
{\tt string-lessp }&{\tt string-greaterp }&{\tt string-not-greaterp }\cr
{\tt string-not-lessp }&{\tt string-not-equal }&{\tt make-string }\cr
{\tt string-trim }&{\tt string-left-trim }&{\tt string-right-trim }\cr
{\tt string-upcase }&{\tt string-downcase }&{\tt string-capitalize }\cr
{\tt nstring-upcase }&{\tt nstring-downcase }&{\tt nstring-capitalize }\cr
{\tt string }& & \cr
\noalign{\vskip -9pt} }}
\caption{String tools}
\endfig
\beginsubsubsection{\datatype Simple-string}
An {\word object} of type {\datatype simple-string}
(a {\datatype simple-string}) is
a {\datatype string} that is not displaced to another {\datatype string},
has no {\word fill pointer}, and is not to have its size adjusted
dynamically after
creation.
%% 2.4.0 2
%% 2.4.0 7
\beginsubsubsection{\datatype List}
The type {\datatype list} is
composed of {\word subtypes}
{\datatype cons} and {\datatype null}, which form an
{\word exhaustive partition}
of {\datatype list}.
An {\word object} of type {\datatype list}
(a {\datatype list})
is a chain of {\datatype conses}
linked by their {\word cdr} components
and terminated by @nil, the empty {\datatype list}.
The {\word car} components of the {\datatype conses}
are called the elements of the {\datatype list}.
For each element of the {\datatype list}
there is a {\datatype cons}. The empty {\datatype list}
has no elements at all.
A {\word dotted list}
is a chain of {\datatype conses}
linked by their {\word cdr} components
and not terminated by @nil.
Unless otherwise specified in this
standard, it is an error to pass a {\word dotted
list} to a {\word function}
that is specified to require a {\datatype list} as an argument.
The following figures contain lists of {\word tools} that are applicable to {\datatype
lists}.
Figure {\chapno--\the\capno} lists the {\datatype cons}
and {\datatype list} operation {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt car }&{\tt cdr }&{\tt caar }\cr
{\tt cadr }&{\tt cdar }&{\tt cddr }\cr
{\tt caaar }&{\tt caadr }&{\tt cadar }\cr
{\tt caddr }&{\tt cdaar }&{\tt cdadr }\cr
{\tt cddar }&{\tt cdddr }&{\tt caaaar }\cr
{\tt caaadr }&{\tt caadar }&{\tt caaddr }\cr
{\tt cadaar }&{\tt cadadr }&{\tt caddar }\cr
{\tt cadddr }&{\tt cdaaar }&{\tt cdaadr }\cr
{\tt cdadar }&{\tt cdaddr }&{\tt cddaar }\cr
{\tt cddadr }&{\tt cdddar }&{\tt cddddr }\cr
{\tt cons }&{\tt tree-equal }&{\tt endp }\cr
{\tt list-length }&{\tt nth }&{\tt first }\cr
{\tt second }&{\tt third }&{\tt fourth }\cr
{\tt fifth }&{\tt sixth }&{\tt seventh }\cr
{\tt eighth }&{\tt ninth }&{\tt tenth }\cr
{\tt rest }&{\tt nthcdr }&{\tt last }\cr
{\tt list }&{\tt list* } & {\tt make-list }\cr
{\tt append } & {\tt copy-list }&{\tt copy-alist }\cr
{\tt copy-tree }& {\tt revappend }&{\tt nconc }\cr
{\tt nreconc }& {\tt push }&{\tt pushnew }\cr
{\tt pop }& {\tt butlast }&{\tt nbutlast }\cr
{\tt ldiff } & &\cr
\noalign{\vskip -9pt} }}
\caption{List tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the
{\datatype list} structure alteration and expression substitution {\word
tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt rplaca }&{\tt rplacd }&{\tt subst }\cr
{\tt subst-if }&{\tt subst-if-not }&{\tt nsubst }\cr
{\tt nsubst-if }&{\tt nsubst-if-not }&{\tt sublis }\cr
{\tt nsublis }& & \cr
\noalign{\vskip -9pt} }}
\caption{List tools - 2}
\endfig
Figure {\chapno--\the\capno} lists the set
operation and association list {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt member }&{\tt member-if } & {\tt member-if-not }\cr
{\tt tailp }&{\tt adjoin }& {\tt union }\cr
{\tt nunion }&{\tt intersection }& {\tt nintersection }\cr
{\tt set-difference }&{\tt nset-difference }& {\tt set-exclusive-or }\cr
{\tt nset-exclusive-or }&{\tt subsetp }& {\tt acons }\cr
{\tt pairlis }&{\tt assoc }& {\tt assoc-if }\cr
{\tt assoc-if-not }&{\tt rassoc }& {\tt rassoc-if }\cr
{\tt rassoc-if-not }&&\cr
\noalign{\vskip -9pt} }}
\caption{List tools - 3}
\endfig
\goodbreak
Following are examples of printed representations of {\datatype lists}:
\screen!
(a . b) ;A dotted pair of a and b
(a.b) ;A list of one element, the symbol named a.b
(a. b) ;A list of two elements a. and b
(a .b) ;A list of two elements a and .b
(a b . c) ;A dotted list of a and b with c at the end; two conses
.iot ;The symbol whose name is .iot
(. b) ;Illegal -- an error is signalled if an attempt is made to read
;this syntax.
(a .) ;Illegal -- an error is signalled.
(a .. b) ;Illegal -- an error is signalled.
(a . . b) ;Illegal -- an error is signalled.
(a b c ...);Illegal -- an error is signalled.
(a @bsl\ . b) ;A list of three elements a, ., and b
(a @vert\ .@vert b) ;A list of three elements a, ., and b
(a @bsl\ ... b) ;A list of three elements a, ..., and b
(a @vert\ ...@vert b) ;A list of three elements a, ..., and b
\endscreen!
∂01-Mar-89 2355 X3J13-mailer Section 2.2 - part 2
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 23:55:24 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA08620; Wed, 1 Mar 89 23:53:21 PST
Message-Id: <8903020753.AA08620@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA08620; Wed, 1 Mar 89 23:53:21 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Mar 89 02:51
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.2 - part 2
%%Types - part 2
\beginsubsubsection{\datatype Ratio}
An {\word object} of type {\datatype ratio\/} (a {\datatype ratio}) is the
mathematical ratio of two {\datatype integers}.
%% 2.1.1 1
\beginsubsubsection{\datatype Integer}
The type {\datatype integer} is composed of
{\word disjoint} {\datatype
fixnum} and {\datatype bignum} subtypes.
An {\word object} of type {\datatype integer\/} (an {\datatype integer}) is a
mathematical integer. There is no limit on the magnitude of an
{\datatype
integer}.
Properties of integers follow:
\beginlist
\itemitem{--} 0 = $-0$
\itemitem{--} The default printed
representation and interpretation for an {\datatype
integer} is decimal.
\endlist
%% 2.1.1 2
\beginsubsubsection{\datatype Fixnum}
An {\word object} of type {\datatype fixnum} (a {\datatype fixnum}) is an
an
{\datatype integer} whose value is between
{\function most-negative-fixnum} and
{\function most-positive-fixnum} inclusive.
Exactly which {\datatype integers} are
{\datatype fixnums} is implementation-dependent.
\beginsubsubsection{\datatype Bignum}
An {\word object} of type {\datatype bignum} (a {\datatype bignum})
is an
{\datatype integer} outside the {\datatype fixnum} range.
\beginsubsubsection{\datatype Float}
The type {\datatype float} is composed of the
{\word disjoint} or identical {\datatype short-float},
{\datatype single-float},
{\datatype double-float}, and {\datatype long-float} subtypes.
An {\word object} of type {\datatype float} (a {\datatype floating}-point
number)
is a (mathematical)
{\datatype rational} of the form
{\it s@centerdot f@centerdot $b↑{e-p}$},
where {\it s} is +1 or @minussign 1, the {\it sign}\rm;
{\it b} is an {\datatype integer}
greater than 1, the {\it base} or {\it radix} of the representation;
{\it p} is a positive {\datatype integer},
the {\it precision} (in base-{\it b} digits) of the floating-point {\datatype
number};
{\it f} is a positive {\datatype integer}
between {\it $b↑{p-1}$} and
{\it $b↑p-1$} (inclusive), the significand;
and {\it e} is an {\datatype integer}, the exponent.
The value of {\it p} and the range of {\it e}
depends on the implementation and on the type of {\datatype floating-point} number
within that implementation.
An {\word object} of type {\datatype short-float\/} is called a {\datatype
short-float}.
An {\word object} of type {\datatype single-float\/} is called a {\datatype
single-float}.
An {\word object} of type {\datatype double-float\/} is called a {\datatype
double-float}.
An {\word object} of type {\datatype long-float\/} is called a {\datatype
long-float}.
Properties of {\datatype floating-point} numbers follow:
\beginlist
\itemitem{--} There is a {\datatype floating-point} number
whose value is zero.
\itemitem{--} If the numeric representation of
{\datatype floating-point} numbers
allows ``minus zero'', it will exist.
\itemitem{--} {\tt $0.0$ = $-0.0$} if there is no minus zero.
\endlist
%% 2.1.3 6
Intermediate between {\datatype short-float} and {\datatype long-float}
are
{\datatype single-float} and {\datatype double-float}.
The precise definition of these categories is implementation-dependent.
The precision (measured in ``bits'', computed as {\it p} log$\sub 2${\it b}\rm)
and the exponent size (also measured in ``bits'', computed as
log$\sub 2$ (maximum exponent value + 1)) is recommended
to be at least as great
as the values in Figure {\chapno--\the\capno}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip
\dimen0 plus .5 fil&#\hfil\cr
\noalign{\vskip -9pt}
\hfil\bf Format &Minimum Precision &Minimum Exponent Size \cr
\noalign{\vskip 2pt\hrule\vskip 2pt}
Short&13 bits&5 bits\cr
Single&24 bits&8 bits\cr
Double&50 bits&8 bits\cr
Long&50 bits&8 bits\cr
\noalign{\vskip -9pt}
}}
\caption{Recommended Minimum Floating-Point Precision and Exponent Size}
\endfig
%% 2.1.3 10
%% 2.1.3 11
%% 2.1.3 18
There may be fewer than four internal
representations for {\datatype floating-point} numbers.
If there are fewer distinct representations, the following fules apply:
\beginlist
\itemitem{--} If there is only one, it is of
the type {\datatype single-float}.
In this representation, an {\word object} is simultaneously of types
{\datatype single-float, double-float, short-float}, and {\datatype
long-float}.
\itemitem{--} Two internal representations can be arranged in either of the
following ways:
\beginlist
\itemitem{\bull} Two {\word types} are provided: {\datatype single-float} and
{\datatype short-float}. An {\word object} is simultaneously of types
{\datatype single-float, double-float}, and {\datatype long-float}.
\itemitem{\bull} Two {\word types} are provided: {\datatype single-float} and
{\datatype double-float}. An {\word object} is simultaneously of types
{\datatype single-float} and {\datatype short-float}, or
{\datatype double-float} and {\datatype long-float}.
\endlist
\itemitem{--} Three internal representations can be arranged in either
of the following ways:
\beginlist
\itemitem{\bull} Three {\word types} are provided: {\datatype short-float},
{\datatype single-float}, and
{\datatype double-float}. An {\word object} can
simultaneously be of type {\datatype double-float} and {\datatype long-float}.
\itemitem{\bull} Three {\word types} are provided:
{\datatype single-float}, {\datatype double-float},
and {\datatype long-float}. An {\word object} can simultaneously
be of types {\datatype single-float} and {\datatype short-float}.
\endlist
\endlist
Figure {\chapno--\the\capno} contains
examples of printed {\datatype floating-point} numbers:
The following rules apply to floating point computations.
%% 12.1.0 1
%% 12.5.0 3
\beginlist
\itemitem{--}
Computations with {\datatype floating-point} numbers are only approximate,
although they are described as if the results
were mathematically accurate.
Two mathematically identical
expressions may be computationally different because of errors
inherent in the floating-point approximation process.
The precision of a {\datatype floating-point} number is not necessarily
correlated with the accuracy of that number.
For instance, 3.142857142857142857 is a more precise approximation
to $\pi$ than 3.14159, but the latter is more accurate.
The precision refers to the number of bits retained in the representation.
When an operation combines a {\datatype short-float} with a
{\datatype long-float},
the result will be a {\datatype long-float}.
@clisp\ {\word functions} assume that the accuracy of
arguments to them does not exceed their precision. Therefore
when two small {\datatype floating-point} numbers
are combined, the result is a small {\datatype floating-point} number.
@clisp\ {\word functions}
never convert automatically from a larger size to a smaller one.
%% 12.1.0 2
\itemitem{--} An error of type {\datatype floating-point-overflow}
or {\datatype floating-point-underflow} should be signalled if a
floating-point computation causes exponent overflow or underflow.
%% 12.1.0 5
\itemitem{--}
The result of a numerical function
is a {\datatype floating-point} number of the largest format among all the
floating-point arguments to the {\word function}.
\endlist
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip
\dimen0 plus .5 fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt 0.0} & ;Floating-point zero in default format
\cr
{\tt 0E0 } & ;Also floating-point zero in default format
\cr
{\tt -.0 } & ;This may be a zero or a minus zero, \cr
& ; depending on the implementation \cr
{\tt 0.} & ;The integer zero, not a floating-point
number! \cr
{\tt 0.0s0 } & ;A floating-point zero in short format
\cr
{\tt 0s0 } & ;Also a floating-point zero in short format
\cr
{\tt 6.02E+23} & ;Avogadro's number, in default format
\cr
{\tt 602E+21} & ;Also Avogadro's number, in default format
\cr
%3.010299957f-1 & ;$log_10$2, in single format \cr
}}
\caption{Examples of Floating-point numbers}
\endfig
%% 2.1.4 1
%% 2.1.4 4
\beginsubsubsection{\datatype Complex}
An {\word object} of type {\datatype complex\/} (a {\datatype complex\/} number)
is represented in Cartesian form, with a real part and an imaginary
part each of which is not a
{\datatype complex\/} number
(i.e. an {\datatype integer}, {\datatype ratio}, or {\datatype floating-point}
number). The parts of a {\datatype complex\/} number
are not necessarily {\datatype floating-point} numbers
but both parts must
be of the same {\word type}: either both are
{\datatype rationals}, or both are
of the same {\datatype floating-point} number {\word subtype}.
When constructing
a {\datatype complex\/} number, if the specified parts are not the same
{\word type}, the parts will be converted to be the same {\word type}
internally (i.e. the {\datatype rational} part
will be converted to
a {\datatype floating-point} number).
An {\word object} of type
{\tt (complex rational)}
will be converted internally and represented thereafter as
a {\datatype rational}
if its imaginary part is an
{\datatype integer} whose value is 0.
%% 12.1.0 6
The following rules apply to {\datatype complex\/} computations:
\beginlist
\itemitem{--}
Except during the execution of irrational and
transcendental {\word forms}, {\datatype complex\/}
numbers never result from a numerical {\word form}
unless one or more of the
arguments is {\datatype complex\/}.
\itemitem{--}
When a non-{\datatype complex\/} number and
a {\datatype complex\/} number are both part of a computation,
the non-{\datatype complex\/}
number is first converted to a {\datatype complex\/} number by providing an
imaginary part of @f[0]\rm.
%% 12.1.0 8
\itemitem{--}
If the result of any computation would be a {\datatype complex\/}
number whose real part is of type {\datatype rational} and whose imaginary
part is zero, the result is
converted to a non-{\datatype complex\/} number
of type {\datatype rational} composed of the
real part.
This rule does not apply to {\datatype complex\/} numbers whose parts
are {\datatype floating-point} numbers.
For example, @f[\#C(5 0)] and @f[5] are not
distinct values in @clisp\ (they are always {\function eql});
@f[\#C(5.0 0.0)] and @f[5.0] are always distinct values in @clisp\
(they are never {\function eql}, although they are {\function equalp}).
\endlist
%% 12.5.3 17
Figure {\chapno--\the\capno} lists
the identities that are obeyed
throughout the applicable portion of the complex domain, even on
the branch cuts:
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0
plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
sin i z = i sinh z & sinh i z = i sin z& arctan i z = i arctanh z \cr
cos i z = cosh z & cosh i z = cos z & arcsinhi z = i arcsin z \cr
tan i z = i tanh z & arcsin i z = i arcsinh z & arctanh i z = i arctan z \cr
\noalign{\vskip -9pt}
}}
\caption{Trigonometric Identities for Complex Domain}
\endfig
%% 2.2.4 1
\beginsubsubsection{\datatype Character}
The type {\datatype character} has a
{\word subtype}
of {\datatype string-char}.
An {\word object} of type {\datatype character} (a {\datatype character})
has three non-negative attributes: code, bits, and font.
%% 13.0.0 3
%% 13.0.0 4
The following rules apply to {\datatype characters}:
\beginlist
\itemitem{--} Two {\datatype characters}
that are {\function eql}, {\function char=}, or {\function char-equal}
are not necessarily {\function eq}.
%% 13.1.0 1
\itemitem{--} Every {\datatype character}
has three attributes: code, bits, and font.
The code attribute is intended to distinguish among the printed glyphs
and formatting functions for {\datatype characters}.
The bits attribute allows extra
flags to be associated with a {\datatype character}. The font attribute permits
a specification of the style of the glyphs (such as italics).
Each of these attributes is a non-negative
{\datatype integer}.
%% 13.5.0 1
\itemitem{--} Four bits of the bits attribute are defined:
Control, Meta, Hyper, and Super.
Each @clisp\ implementation provides these bit definitions for compatibility,
even if it does not support the bits.
\itemitem{--} The total ordering on
{\datatype characters} is guaranteed to have the following
properties:
\beginlist
%% 13.2.0 27
\itemitem{\bull} If two {\datatype characters}
have the same bits and font attributes,
then their ordering by {\function char<} is consistent with the numerical
ordering by the predicate {\function <} on their code attributes.
%% 13.2.0 28
\itemitem{\bull} If two {\datatype characters}
differ in any attribute (code, bits, or font), then they
are different.
%% 13.2.0 29
\itemitem{\bull} The total ordering is not necessarily the same as the total
ordering on the {\datatype integers}
produced by applying @Funref[char-int] to the
{\datatype characters}.
%% 13.2.0 30
\itemitem{\bull}
While alphabetic {\datatype characters} of a given case must be
properly ordered, they need not be contiguous; it is permitted for
uppercase and lowercase letters to be interleaved.
Thus @f[(char<= \#{\char '134}a x
\#{\char '134}z)] is not
a valid way of determining whether or not @f[x] is a
lowercase letter.
%% 13.2.0 34
\itemitem{\bull}
The ordering may depend on the font information. For example, an implementation
might decree that {\tt (char-equal \#{\char '134}p \#{\char '134}{\it p})}
be true, but that
{\tt (char-equal \#{\char '134}p \#{\char '134}$\pi$)}
be false (where {\tt \#{\char '134}$\pi$} is a
lowercase @f[p] in some font). Assuming italics to be in font 1
and the Greek alphabet in font 2, this is the same as saying that
{\tt (char-equal \#0{\char '134}p \#1{\char '134}p)}
may be true and at the same time
{\tt (char-equal \#0{\char '134}p \#2{\char '134}p)} may be false.
\endlist
%% 13.2.0 25
%% 13.2.0 26
The standard alphanumeric characters obey the following partial ordering:
@Lisp
A<B<C<D<E<F<G<H<I<J<K<L<M<N<O<P<Q<R<S<T<U<V<W<X<Y<Z
a<b<c<d<e<f<g<h<i<j<k<l<m<n<o<p<q<r<s<t<u<v<w<x<y<z
0<1<2<3<4<5<6<7<8<9
either 9<A or Z<0
either 9<a or z<0
@Endlisp
This implies that alphabetic ordering holds within each case (upper and
lower), and that the digits as a group
are not interleaved with letters. However, the ordering
or possible interleaving of
uppercase letters and lowercase letters is unspecified.
The following figures contain lists of {\word tools} applicable to {\datatype
characters}.
Figure {\chapno--\the\capno} lists the {\datatype character}
attribute and predicate {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt char-code-limit }&{\tt char-font-limit }&{\tt char-bits-limit }\cr
{\tt standard-char-p }&{\tt graphic-char-p }&{\tt string-char-p }\cr
{\tt alpha-char-p }&{\tt upper-case-p }&{\tt lower-case-p }\cr
{\tt both-case-p }&{\tt digit-char-p }&{\tt alphanumericp }\cr
{\tt char= }&{\tt char/= }&{\tt char< }\cr
{\tt char> }&{\tt char<= }&{\tt char>= }\cr
{\tt char-equal }&{\tt char-not-equal }&{\tt char-lessp }\cr
{\tt char-greaterp }&{\tt char-not-greaterp }&{\tt char-not-lessp }\cr
\noalign{\vskip -9pt} }}
\caption{Character tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the
{\datatype character} construction, conversion, and control-bit {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt char-code }&{\tt char-bits }&{\tt char-font }\cr
{\tt code-char }&{\tt make-char }&{\tt character }\cr
{\tt char-upcase }&{\tt char-downcase }&{\tt digit-char }\cr
{\tt char-int }&{\tt int-char }&{\tt char-name }\cr
{\tt name-char }&{\tt char-control-bit }&{\tt char-meta-bit }\cr
{\tt char-super-bit }&{\tt char-hyper-bit }&{\tt char-bit }\cr
{\tt set-char-bit }& & \cr
\noalign{\vskip -9pt} }}
\caption{Character tools - 2}
\endfig
%% 2.2.5 1
\beginsubsubsection{\datatype String-char}
The type {\datatype string-char} has a {\word subtype} of {\datatype
standard-char}.
An {\word object} of type {\datatype string-char} (a {\datatype string-char})
is a {\datatype character\/} whose bit and font
attributes are {\datatype integers}
whose values are 0.
\beginsubsubsection{\datatype Standard-char}
{\word Objects} of type {\datatype standard-char} ({\datatype standard-chars})
are listed
in ``Object Syntax''.
%% 2.3.0 1
%% 2.3.0 2
\beginsubsubsection{\datatype Symbol}
An {\word object} of type {\datatype symbol} (a {\datatype symbol})
is a data structure
composed of a print namestring,
a package name, and a
property list. A {\datatype symbol} may be retrieved from
a {\datatype package} given a print name.
{\datatype Symbols} can be interned or uninterned in a {\datatype package}.
%% 11.0.0 11
To intern a {\datatype symbol} in a {\datatype package} means to cause the
{\datatype symbol}
to be accessible in the {\datatype package} if it were not already.
See {\function intern}.
If the {\datatype symbol} were previously unowned, then the
{\datatype package} it is being
interned in becomes its owner (home package); but
if the {\datatype symbol}
was previously owned by another {\datatype package}, that other {\datatype
package}
continues to own the {\datatype symbol}.
%% 10.3.0 2
%% 10.3.0 3
Interned symbols are created automatically by {\function intern};
If a given print name does not have a corresponding
{\datatype symbol} in the specified or
inherited {\datatype packages}, a {\datatype symbol} is
created for that print name.
the first time
something (such as {\function read})
asks the package system for a {\datatype symbol} with a given print name,
that {\datatype symbol} is automatically created.
%% 11.0.0 12
To unintern a {\datatype symbol} from a
{\datatype package} means to cause it to be not
present and, additionally, to make the {\datatype symbol} uninterned if the
{\datatype package} is the {\datatype symbol's} home package.
See @Funref[unintern]\rm.
%% 10.3.0 1
{\datatype Symbols} have the following
components, the first three of which are user-visible.
%% 10.0.0 3
%% 10.0.0 4
%% 10.1.0 1
%% 10.1.0 2
%% 10.1.0 3
\beginlist
\itemitem{\bf Property list}
The property list is an even-length
{\datatype list} of zero or more
elements
whose even-numbered components (calling the first component zero)
are indicators (no duplicates on the same
property list are allowed)
and whose odd-numbered components are {\word objects}.
The property list of a {\datatype symbol}
may be destructively replaced.
A property-value pair in the property list may be added or updated.
%% 10.1.0 4
When a {\datatype symbol} is created, its property list is initially empty.
Properties are created by using {\function setf} of @Macref[get]\rm.
Any form acceptable to {\function setf\/}
as a {\word
generalized reference} can be used to store the property list.
%% 10.0.0 5
%% 10.2.0 1
\itemitem{\bf Print name}
The print name is a {\datatype string},
used to identify the {\datatype symbol}.
Every
{\datatype symbol} has a print name, and that
name can not be altered.
The print name is used as the external representation of the
{\datatype symbol}.
If the {\datatype characters} in the {\datatype string}
of the print name are typed in to {\function read}
(with suitable escape conventions for certain characters),
it is interpreted as a reference to that {\datatype symbol}
(if it is {\word interned}); and if the {\datatype symbol}
is printed, {\function print} outputs the
print name.
Given the print name of a {\datatype symbol}
as a {\datatype string} the
{\datatype symbol} can be obtained.
Every time a {\datatype symbol} with a certain print name is referenced,
the same ({\function eq}) {\datatype symbol } is returned.
{\datatype Symbols} are organized into
{\datatype packages}, and all the {\datatype symbols}
in a {\datatype package} are uniquely
identified by print name.
A {\datatype symbol\/}'s print name can be composed
of any {\datatype string-char}. Space and parenthesis characters
must be preceded by an
escape character in order to be a part of a {\datatype symbol\/}'s print name.
A {\datatype symbol\/}'s print name must contain escape characters if
\beginlist
\itemitem{\bull} It would be composed of only periods
(.).
\itemitem{\bull} It would be syntactically identical to a
{\datatype number}.
\endlist
Any double quote in the name
of a {\datatype symbol} written using vertical-bar notation need not be
preceded by a @bsl.
%% 10.0.0 4
%% 10.3.0 4
%% 11.0.0 8
%% 11.0.0 10
%% 11.0.0 28
\itemitem{Package cell}
The package cell
contains a pointer to the {\datatype symbol's}
home {\datatype package}, if
it is interned in and owned by any {\datatype package},
or @false\ if it is uninterned (not owned by a {\datatype package}).
The package cell
may be accessed by @Funref[symbol-package]\rm.
A {\datatype symbol} may
appear in many {\datatype packages}, but it can have at most
one home {\datatype package}.
The same print name may refer to different {\datatype symbols} in
different {\datatype packages}.
%% 10.0.0 8
\itemitem{Other components}
A {\datatype symbol} may have other components for use by the
implementation.
\endlist
Following is the list of
{\word tools} that are applicable to the property list of
{\datatype symbols}: {\tt get}, {\tt remprop},
{\tt symbol-plist}, {\tt getf}, {\tt remf}, and
{\tt get-properties}.
The function {\tt symbol-name} is used to access the print name of
a symbol.
Following is the list of
{\word tools} that are applicable to creating
{\datatype symbols}: {\tt make-symbol}, {\tt copy-symbol},
{\tt gensym}, {\tt gentemp}, {\tt symbol-package}, and
{\tt keywordp}.
∂02-Mar-89 0834 X3J13-mailer Section 2.2 - part 4
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Mar 89 08:33:46 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA02028; Thu, 2 Mar 89 08:31:42 PST
Message-Id: <8903021631.AA02028@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA02028; Thu, 2 Mar 89 08:31:42 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Mar 89 07:40
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.2 - part 4
%%Types - part 4
\beginsubsubsection{\datatype Cons}
An {\word object} of type {\datatype cons}
is called a {\word cons}.
%% 2.5.0 1
\beginsubsubsection{\datatype Array\/}
The type {\datatype array\/} has {\word subtypes} {\datatype vector}
and {\datatype simple-array}.
An {\word object} of type {\datatype array\/}
(an {\datatype array\/})
contains {\word objects} arranged according
to a Cartesian coordinate system.
%% 17.0.0 3
The following rules apply to {\datatype arrays\/}.
\beginlist
\itemitem{--} An {\datatype array\/} contains components arranged according
to a rectilinear coordinate system.
%% 17.0.0 4
An {\datatype array\/}
may be a general {\datatype array\/}, meaning each element may be any @xlisp\
{\word object}, or it may be a specialized {\datatype array\/},
meaning that each element
must be of a restricted {\word type}.
%% 2.5.0 3
%% 2.5.0 4
\itemitem{--}
In principle, an
{\datatype array\/} in @clisp\ may have any number of dimensions, including zero.
It is permissible for a dimension to be zero, in which case
the {\datatype array\/}
has no elements, and any attempt to access an element
is an error. However, other properties of the {\datatype array\/},
such as the
dimensions themselves, may be used.
If the rank is zero, then there are no dimensions, and the
product of the dimensions is then by definition 1.
A zero-rank {\datatype array\/} therefore has a single element.
\itemitem{--} An implementation of may impose a limit on the rank of an
{\datatype array\/},
but this limit may not be smaller than 7.
The value of @conref[array-rank-limit] is the implementation's limit on
{\datatype array\/} rank.
\itemitem{--}Each dimension is a non-negative
{\datatype integer}; if any dimension of an {\datatype array\/} is zero,
the {\datatype array\/} has no elements.
%% 17.0.0 5
\itemitem{--}
General {\datatype vectors} may contain
any @xlisp\ {\word object}. {\datatype Vectors}
whose elements are restricted to type
{\datatype string-char} are called {\datatype strings}.
{\datatype Vectors} whose elements are
restricted to type {\datatype bit} are called {\datatype bit-vectors}.
%% 17.5.0 4
\itemitem{--}
Only {\datatype vectors} may have {\word fill pointers};
multidimensional {\datatype arrays\/} may not.
A multidimensional {\datatype array\/}
that is displaced to a {\datatype vector} that has
a {\word fill pointer} can be created.
%% 2.5.0 8
\itemitem{--}
Multidimensional {\datatype arrays\/}
store their components in row-major order;
that is, internally a multidimensional {\datatype array\/}
is stored as a one-dimensional
{\datatype array\/},
with the multidimensional index sets ordered lexicographically,
last index varying fastest.
%% 2.5.0 5
\itemitem{--}
An {\datatype array\/} element is specified by a series of indices.
The length of the series must equal the rank of the {\datatype array\/}.
Each index must be a non-negative {\datatype integer} strictly less than
the corresponding {\datatype array\/} dimension. {\datatype Array\/}
indexing is zero-origin.
\itemitem{--}
%% 17.1.0 13
When an array A is given as
the @Kwd[displaced-to] argument to {\function make-array}
when creating array B,
then array B is said to be displaced to array A. The
total number of elements in an {\datatype array\/},
called the total size of the {\datatype array\/},
is calculated as the product of all the dimensions.
It is required that the total size of A be no smaller than the sum
of the total size of B plus the offset @f[n] supplied by
the @Kwd[displaced-index-offset]
argument. The effect of displacing is that array B does not have any
elements of its own, but instead maps accesses to itself into
accesses to array A. The mapping treats both {\datatype arrays\/} as if they
were one-dimensional by taking the elements in row-major order,
and then maps an access to element @f[k] of array B to an access to element
@f[k]+@f[n] of array A.
\itemitem{--}
When {\keyword displaced-to} is supplied to {\function make-array},
{\keyword displaced-index-offset} is made to be the
index offset of the \array.
If {\keyword displaced-index-offset} is not supplied,
the index offset is zero.
\endlist
The following figures contain lists of {\word tools} that are applicable to {\datatype
arrays}.
Figure {\chapno--\the\capno} lists the {\datatype array\/}
creation, access, and information {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt make-array }&{\tt array-rank-limit }&{\tt array-dimension-limit }\cr
{\tt array-total-size-limit }&{\tt vector }&{\tt aref }\cr
{\tt svref }&{\tt array-element-type }&{\tt array-rank }\cr
{\tt array-dimension }&{\tt array-dimensions }&{\tt array-total-size }\cr
{\tt array-in-bounds-p }&{\tt array-row-major-index }&{\tt adjustable-array-p }\cr
{\tt upgraded-array-element-type} & {\tt upgraded-complex-part-type} & \cr
\noalign{\vskip -9pt} }}
\caption{Array tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the {\word tools}
for operations on {\datatype arrays} of bits.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt bit }&{\tt sbit }&{\tt bit-and }\cr
{\tt bit-ior }&{\tt bit-xor }&{\tt bit-eqv }\cr
{\tt bit-nand }&{\tt bit-nor }&{\tt bit-andc1 }\cr
{\tt bit-andc2 }&{\tt bit-orc1 }&{\tt bit-orc2 }\cr
{\tt bit-not }&&\cr
\noalign{\vskip -9pt} }}
\caption{Array tools - 2}
\endfig
Figure {\chapno--\the\capno} lists
the {\datatype array\/} {\word fill pointer}
and dimension modification {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt array-has-fill-pointer-p }&{\tt fill-pointer }&{\tt vector-push}\cr
{\tt vector-push-extend }&{\tt vector-pop }&{\tt adjust-array }\cr
\noalign{\vskip -9pt} }}
\caption{Array tools - 3}
\endfig
%% 2.5.0 9
\beginsubsubsection{\datatype Simple-array}
The type {\datatype simple-array\/}
has {\word subtypes} {\datatype
simple-vector}, {\datatype simple-string}, and {\datatype simple-bit-vector}.
An {\word object} of type {\datatype simple-array\/}
(a {\datatype simple-array\/}) is
an {\datatype array\/}
that is not displaced to another {\datatype array\/},
has no {\word fill pointer}, and
is not to have its size adjusted dynamically after
creation.
%% 2.5.1 4
Implementations may provide certain specialized representations of
{\datatype arrays\/}
for efficiency in the case where all the components are of
the same specialized type.
All implementations are required to provide specialized {\datatype arrays\/}
of bits, that is, {\datatype objects} of type {\tt (array bit)};
the one-dimensional instances of
this specialization are called {\datatype bit-vectors}.
All implementations
provide specialized {\datatype arrays\/}
for the cases when the components
are {\datatype characters} (or rather,
a special subset of the {\datatype characters});
the one-dimensional instances of
this specialization are called {\datatype strings}.
%% 2.10.0 1
\beginsubsubsection{\datatype Stream}
An {\word object} of type {\datatype stream} (a {\datatype stream})
is a source or sink of data.
%% 21.0.0 3
%% 21.0.0 4
For example, character {\datatype streams}
produce or absorb {\datatype characters};
binary {\datatype streams} produce or absorb {\datatype integers}.
%% 21.0.0 3
A {\datatype stream}, whether a character stream or a binary
stream, may be input-only, output-only, or bidirectional.
What operations may be performed on a {\datatype stream} depends on which
type of {\datatype stream} it is.
%% 22.0.0 3
%All input/output operations are performed on {\datatype streams}
%of various kinds.
The following figures contain lists of {\word tools} that are applicable to {\datatype
streams}.
Figure {\chapno--\the\capno} lists the standard {\datatype streams}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
@var[standard-input] & @var[standard-output] & @var[error-output] \cr
@var[query-io] & @var[debug-io] & @var[terminal-io] \cr
@var[trace-output] & &\cr
\noalign{\vskip -9pt} }}
\caption{Stream tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the {\datatype stream}
creation and manipulation {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt make-synonym-stream }&{\tt make-broadcast-stream }\cr
{\tt make-concatenated-stream} & {\tt make-two-way-stream }\cr
{\tt make-echo-stream }&{\tt make-string-input-stream }\cr
{\tt make-string-output-stream }&{\tt get-output-stream-string }\cr
{\tt with-open-stream } & {\tt with-input-from-string }\cr
{\tt with-output-to-string }& {\tt streamp } \cr
{\tt input-stream-p }&{\tt output-stream-p }\cr
{\tt stream-element-type } & {\tt close } \cr
\noalign{\vskip -9pt} }}
\caption{Stream tools - 2}
\endfig
\beginsubsubsection{\datatype Hash-table}
An {\word object} of type {\datatype hash-table} (a {\datatype hash-table})
contains keys and values.
%% 16.0.0 3
A {\datatype hash-table} maps a given
@xlisp\ {\word object} to another @xlisp\ {\word object} via a hash
mechanism.
Each {\datatype hash-table}
has a set of entries, each of which associates a
key with a value.
Figure {\chapno--\the\capno} lists the
{\word tools} that are applicable to {\datatype hash-tables}.
The following rules apply to {\datatype hash-tables}.
%% 16.0.0 4
\beginlist
\itemitem{--}
A {\datatype hash-table} can only associate one value with a given
key. Adding a value to a {\datatype hash-table} is a destructive operation;
the {\datatype hash-table} is modified.
%% 16.0.0 5
\itemitem{--}
There are three kinds of {\datatype hash-tables} -- those whose keys
are compared with {\function eq}, those whose keys
are compared with {\function eql}, and those whose keys
are compared with {\function equal}.
%% 16.0.0 6
\itemitem{--}
{\datatype Hash-tables} are created by
{\function make-hash-table}.
{\function gethash} is used to look up a key and find
the associated value.
New entries are added
to {\datatype hash-tables} using @Macref[setf] with {\function gethash}.
{\function remhash} is used to remove an entry.
For example:
@Lisp
(setq a (make-hash-table)) @EV #<Hash Table...>
(setf (gethash 'color a) 'brown) @EV BROWN
(setf (gethash 'name a) 'fred) @EV FRED
(gethash 'color a) @EV BROWN T
(gethash 'name a) @EV FRED T
(gethash 'pointy a) @EV @false @false
@Endlisp
%% 16.0.0 7
In this example, the {\word symbols} @f[color] and @f[name] are being used as
keys, and the {\word symbols} @f[brown] and @f[fred] are being used as the
associated values. The {\datatype hash-table}
has two items in it, one of which
associates from @f[color] to @f[brown]\rm, and the other of which
associates from @f[name] to @f[fred]\rm.
%% 16.0.0 8
\itemitem{--}
A key or a value may be any {\word object}.
%% 16.0.0 9
\itemitem{--}
When a {\datatype hash-table}
is first created, it has a size, which is the
maximum number of entries it can hold. Usually the actual capacity of
the table is somewhat less, since the hashing is not perfectly
collision-free. If so many entries are
added that the capacity is exceeded, the {\datatype hash-table}
will automatically
grow, and the entries will be rehashed (new hash values will be
recomputed, and everything will be rearranged so that the fast hash
lookup still works). This is transparent to the caller; it all happens
automatically.
%% 16.0.0 10
\itemitem{--}
The cases
of @f[nil] as a value and no entry in the {\datatype hash-table}
can be distinguished by the second value returned by {\function gethash}.
\endlist
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt make-hash-table }&{\tt hash-table-p }&{\tt gethash }\cr
{\tt remhash }&{\tt maphash }&{\tt clrhash }\cr
{\tt hash-table-count }&{\tt sxhash }&\cr
\noalign{\vskip -9pt} }}
\caption{Hash-table tools}
\endfig
%% 2.7.0 1
%% 22.1.5 2
\beginsubsubsection{\datatype Readtable}
An {\word object} of type {\datatype readtable} (a {\datatype readtable})
maps {\datatype
characters\/} into syntax
types for the {\word Lisp reader} (see ``Character Reader'').
A {\datatype readtable}
contains a macro
definition for
each {\datatype character} with macro character syntax.
Figure {\chapno--\the\capno} lists the
{\word tools} that are applicable to {\datatype readtables}.
See ``Object Syntax''.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
@var[readtable] & {\tt copy-readtable} \cr
{\tt readtablep } & {\tt set-syntax-from-char }\cr
{\tt set-macro-character }&{\tt get-macro-character }\cr
{\tt make-dispatch-macro-character }&{\tt set-dispatch-macro-character }\cr
{\tt get-dispatch-macro-character} & \cr
\noalign{\vskip -9pt} }}
\caption{Readtable tools}
\endfig
∂02-Mar-89 0930 X3J13-mailer cs proposal comments
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:30:00 PST
Date: Thu, 02 Mar 89 02:27:38 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890302.022738.baggins@almvma>
Subject: cs proposal comments
Just a reminder, please send comments/straw ballots to x3j13 and
not the characters mailing list.
Regards,
Thom
∂02-Mar-89 0928 X3J13-mailer forwarding note from gregor from larry
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:27:42 PST
Date: Wed, 01 Mar 89 13:15:48 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890301.131548.baggins@almvma>
Subject: forwarding note from gregor from larry
=========================================================================
Received: from Xerox.COM by ibm.COM on 02/23/89 at 10:00:35 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 FEB 89 09:56:23 PST
Date: Thu, 23 Feb 89 09:56 PST
From: Gregor.pa@Xerox.COM
Subject: [masinter.pa: Re: cs proposal straw vote]
To: baggins@IBM.com
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
Included-msgs: The message of 22 Feb 89 20:59 PST from masinter.pa
Included-References: The message of 22 Feb 89 12:08 PST from
baggins@IBM.com
Message-ID: <19890223175611.1.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
Larry asked me to forward this to you as the official Xerox position on
the straw ballot.
Date: Wed, 22 Feb 89 20:59 PST
From: masinter.pa
My personal opinion:
CHAR-FONT-UNUSED-CHAR-BITS-NONPORTABLE:
Eliminate of font and bit attributes.
**** Yes
Add rules for an implementation supporting attributes.
**** No. Attributes can be done as
attributes of subclass of CHARACTER.
Remove any description of
implementation-supported attributes.
Remove CHAR-FONT-LIMIT
Remove CHAR-BITS-LIMIT
Remove INT-CHAR
Remove CHAR-BITS
Remove CHAR-FONT
Remove MAKE-CHAR
Remove CHAR-CONTROL-BIT
Remove CHAR-META-BIT
Remove CHAR-SUPER-BIT
Remove CHAR-HYPER-BIT
Remove CHAR-BIT
Remove SET-CHAR-BIT
**** Yes.
Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
Proposal:
Remove CHAR-INT
**** YES
Issue: CHARACTER-TYPE-RESTRICTIVE
Define BASE-CHARACTER as a subtype of STRING.
Standard characters are a subset of the base
characters.
STANDARD-CHAR type is replaced by (CHARACTER :STANDARD)
Remove the semi-standard characters.
**** NO.
Define (CHARACTER :STANDARD) in the same
way that STANDARD-CHAR used to be.
Define BASE-CHARACTER as
(upgraded-array-element-type '(CHARACTER :STANDARD)).
Remove the semi-standard characters.
<<You might argue that this has the same effect, but
it doesn't.>>
Issue: STRING-TYPE-RESTRICTIVE
Proposal:
Define STRING as a union type
*** YES
STRING used as a type specifier for object creation
means (VECTOR CHARACTER)
*** YES
All string functions operate as specified on any
string object except it is an error to insert
an extended character into a base string.
*** NO. It is an error to insert an object in an
array where the object is not of the element type
of the array.
<<You might argue this has the same effect, but
my wording here is more general.>>
Extend the COERCE function to allow coercion from
base string to extended string.
*** NO. This is unnecesarry. COERCE already
coerces from one vector type to another.
Issue: STRING-TYPE-ABBREVIATIONS
Proposal:
Add BASE-STRING
Add GENERAL-STRING
*** NO. Unnecessary, confusing, clutter.
Issue: SIMPLE-STRING-TYPE-RESTRICTIVE
Proposal:
Define SIMPLE-STRING as a union type
Define SIMPLE-STRING as a type specifier for object
creation means (SIMPLE-ARRAY CHARACTER (size))
*** NO. Confusing. Poor performance model.
SIMPLE isn't simple.
Issue: SIMPLE-STRING-TYPE-ABBREVIATIONS
Proposal:
Add SIMPLE-BASE-STRING
Add SIMPLE-GENERAL-STRING
*** NO, even if SIMPLE-STRING-TYPE-RESTRICTIVE adopted.
Unnecessary. Useless clutter.
Issue: FILE-EXTERNAL-REPRESENTATION
Proposal:
Add :EXTERNAL-CODED-CHARACTER-FORMAT keyword to OPEN
*** NO, wrong name. Unspecified. Better to omit than to
add with unspecified or poorly specified behavior.
Better to add as "future direction" in standard than in current
state.
Issue: STRING-BINARY-WIDTH
Proposal:
Add :EXTERNAL-CODED-STRING-LENGTH function
*** NO, even if you meant to omit the :. CL currently doesn't
admit that text and binary can be intermixed. No standard
way to use information returned. No relation to
FILE-POSITION defined.
Issue: CHAR-CODE-NON-PORTABLE
Proposal:
Add CHAR-CCS-VALUE function
*** NO. Requires lots of implementation mechanism.
Of limited use in nearly all situations.
Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
Proposal:
Introduce the concept of Registries
*** IF modified; should only suggest names of
character repertoires, and name at least
STANDARD HIRAGANA KATAKANA
GREEK. Standardization of repertoire elements
to be specified in future.
Standardize on #\registry:id
*** YES, as suggestion
add all-implemented-registries
*** NO
Add *ALL-CHARACTER-REGISTRY-NAMES* variable
*** NO
Add FIND-CHAR function
*** NO, NAME-CHAR will do
Add CHAR-LABEL function
*** NO, CHAR-NAME will do
Add CHAR-REGISTRY-NAME function
*** NO, string processing on CHAR-NAME will do
New syntax for CHARACTER type specifier
*** YES
New #\label:registry character name syntax
*** ??? This was already mentioned
New argument to CHARACTERP
*** YES.
-------
∂02-Mar-89 0928 X3J13-mailer forwarding mail from gray
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:28:08 PST
Date: Wed, 01 Mar 89 15:59:07 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890301.155907.baggins@almvma>
Subject: forwarding mail from gray
=========================================================================
Received: from dsg.csc.ti.com by ibm.COM on 03/01/89 at 10:29:25 PST
Received: from ti.com by RELAY.CS.NET id aa05395; 28 Feb 89 23:18 EST
Received: by ti.com id AA00500; Tue, 28 Feb 89 22:18:18 CST
Received: from Kelvin by tilde id AA21544; Tue, 28 Feb 89 22:08:43 CST
Message-Id: <2813717283-5615057@Kelvin>
Sender: GRAY%kelvin.csc.ti.com@RELAY.CS.NET
Date: Tue, 28 Feb 89 22:08:03 CST
From: David N Gray <Gray%dsg.csc.ti.com@RELAY.CS.NET>
To: Thom Linden <baggins@IBM.COM>
Cc: CL-Characters@SAIL.STANFORD.EDU, Bartley%mips.csc.ti.com@RELAY.CS.NET,
Waldrum%tilde.csc.ti.com@RELAY.CS.NET
Subject: Re: cs proposal straw vote
In-Reply-To: Msg of Wed, 22 Feb 89 12:08:15 PST from Thom Linden <baggins@IBM.com>
> I would like to take a straw vote on various components of
> the Characters proposal. The primary intent is to resolve the
> actual list of items to be voted upon at the March meeting.
> Let me know if you think some items should be separated or
> combined
...
> Issue: CHAR-FONT-UNUSED-CHAR-BITS-NONPORTABLE
> Problem: CHAR-FONT isn't used, CHAR-BITS isn't portable.
> Proposal:
> Eliminate of font and bit attributes.
> Add rules for an implementation supporting attributes.
> Redefine STRING-CHAR as implementation defined.
> Remove CHAR-FONT-LIMIT
> Remove CHAR-BITS-LIMIT
> Remove INT-CHAR
> Remove CHAR-BITS
> Remove CHAR-FONT
> Remove MAKE-CHAR
> Remove CHAR-CONTROL-BIT
> Remove CHAR-META-BIT
> Remove CHAR-SUPER-BIT
> Remove CHAR-HYPER-BIT
> Remove CHAR-BIT
> Remove SET-CHAR-BIT
Yes, I can accept this.
---
> Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
> Problem: CHAR-INT behavior is CHAR-CODE unless implementation
> defined attributes are supported.
> Proposal:
> Remove CHAR-INT
I had to stop and think about why this wasn't part of the previous issue.
Perhaps the thought was that a portable way to turn all of a character into
a number (e.g. for a hash code) would be desirable even if only some
implementations support attributes? That sounds like a legitimate
concern, so I vote No.
--
> Issue: CHARACTER-TYPE-RESTRICTIVEC
> Problem: CHARACTER type doesn't allow thin & fat characters.
> Proposal: a
> Define BASE-CHARACTER as a subtype of STRING. a
> Standard characters are a subset of the base
> characters.
> STANDARD-CHAR type is replaced by (CHARACTER :STANDARD)
> Remove the semi-standard characters.
I have been unable to imagine the reason for linking semi-standard
characters with fat characters; these should be separate issues.
Yes to fat characters.
---
No to removing the semi-standard characters. I still have yet to hear a
-- plausible rationale for doing this.
> Issue: STRING-TYPE-RESTRICTIVE
> Problem: STRING type doesn't allow thin & fat strings.
> Proposal: a
> Define STRING as a union type a
> STRING used as a type specifier for object creation
> means (VECTOR CHARACTER)
> All string functions operate as specified on any a
> string object except it is an error to insert
> an extended character into a base string.
> Extend the COERCE function to allow coercion from a
> base string to extended string.
Yes.
---
> Issue: STRING-TYPE-ABBREVIATIONS
> Problem: new types are awkward to name, want abbreviations.
> Proposal: ne
> Add BASE-STRING
> Add GENERAL-STRING
Yes.
---
> Issue: SIMPLE-STRING-TYPE-RESTRICTIVE
> Problem: SIMPLE STRING type doesn't allow thin & fat strings.
> Proposal: a
> Define SIMPLE-STRING as a union type a
> Define SIMPLE-STRING as a type specifier for object
> creation means (SIMPLE-ARRAY CHARACTER (size))
Yes.
---
> Issue: SIMPLE-STRING-TYPE-ABBREVIATIONS
> Problem: new types are awkward to name, want abbreviations.
> Proposal: ne
> Add SIMPLE-BASE-STRING
> Add SIMPLE-GENERAL-STRING
Yes.
---
> Issue: FILE-EXTERNAL-REPRESENTATION
> Problem: can't specify external encoding even when there are lots
> Proposal:
> Add :EXTERNAL-CODED-CHARACTER-FORMAT keyword to OPEN
Yes.
---
> Issue: STRING-BINARY-WIDTH
> Problem: Can't find out how many bytes a string will take when written as
> text
> Proposal:
> Add :EXTERNAL-CODED-STRING-LENGTH function
No; I'm not sure that this has been adequately thought out.
--
> Issue: CHAR-CODE-NON-PORTABLE
> Problem: no way to talk about well-known external coding methods, only
> internal codes
> Proposal:
> Add CHAR-CCS-VALUE function
Yes, although I'm not too happy about the name; "value" doesn't really say
--- much. Why not CHAR-CCS-INDEX ? Or CHAR-EXTERNAL-CODE ? Yes also to
the inverse function.
> Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
> Problem: Can't portably talk about non-standard characters
> Proposal:
> Introduce the concept of Registries
> Standardize on #\registry:id, add all-implemented-registries
> Add *ALL-CHARACTER-REGISTRY-NAMES* variable
> Add FIND-CHAR function
> Add CHAR-LABEL function
> Add CHAR-REGISTRY-NAME function
> New syntax for CHARACTER type specifier
> New #\label:registry character name syntax
> New argument to CHARACTERP
No. I'm not convinced that this approach is feasible or even necessary.
--- There appears to be a great deal of machinery being created solely to
support the premise stated in section 2.2 that all characters need to
be decomposable into one and only one name. I don't see the need for
that.
∂02-Mar-89 0929 X3J13-mailer cs proposal comments
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:29:33 PST
Date: Thu, 02 Mar 89 02:20:21 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890302.022021.baggins@almvma>
Subject: cs proposal comments
>> But if we decide that "my alpha" _is_ the same as "your alpha", then which
>> of our languages' registry gets to include it? I can see a lot of
>> confusion over characters that are used the same in more than one
>> language.
I don't see the confusion. German, English, Italian, etc. have a large
overlap of characters. One would expect these to all be in a single
registry, eg. Latin. Again, the important factor is that a character
is uniquely named. There is no advantage of one registry over another.
>>
>> I'm not so much concerned with who decides this as with whether this
>> approach is even feasible. The lack of even a "for example" scenario of
>> how this might work leaves me with a lot of doubts about whether it _can_
>> work. Also, it is not apparent why anyone outside the Common Lisp
>> community would have any interest in participating in such a standards
>> effort.
I believe other languages have the same problems as Lisp. For example,
COBOL has standardized names for coded character sets in
their I/O interface. In particular, SC22 wants to address the
international character handling issues across all (prog.)languages.
I'm attending an SC22 ad hoc committee meeting on characters next
week (and will let this forum know what interest I find).
>>
>>
>> Page 7 of the draft dated February 21 says that
>>
>> "The proposed ISO Character Registry Standard is fixed; an
>> implementation may not extend a standard registry's constituent
>> set of characters beyond the standard definition."
>>
>> That says to me that if an implementation is going to add a character,
>> then it can only be added to an implementation-defined registry. What
>> happens then if a new edition of the registry standard includes that
>> character in one of the standard registries? Since a character is not
>> permitted to be a member of more than one registry, that immediately
>> becomes an incompatible change for anyone who has been using that
>> character. Consequently, even extensions by standards revision will be
>> discouraged. That seems quite non-extensible to me.
Nothing prevents the implementation from providing a warning message
and behaving properly for some period of time. Users are encouraged
to use a 'new' standardized name since that name has a portable
meaning.
But, what the statement says to me is that if I use a name in the
standard registry, I have a guarentee that it does not have an
implementation unique meaning. Also, it is impossible for an
implementation to add character names which conflict with any
'new' standardized character.
>>
>>
>> So CHAR< etc. have no portable meaning unless both arguments are standard
>> characters in one of the partial ordering groups on page 237 of CLtL?
>> If you are going to have a Greek alphabet that is required to be disjoint
>> from the Latin alphabet anyway, wouldn't you want to know that the Greek
>> letters could be sorted in the expected order?
Well, I don't know the 'expected' order for Greek. In general, the
expected order is culturally dependent and using CHAR< as a sorting
mechanism is not sufficient. If we take the Latin registry
as including accented characters, there are different orderings
depending on whether you are in a Spanish, German, Danish, etc.
context. For Common Lisp to impose a single one is certainly
be wrong. In general, I don't think the ordering of individual
characters by CHAR< is as important as standardized definitions
of ordering strings for culturally expected results (such as, dictionary
ordering).
>>
>> > >> Page 25 section A.4.5 doesn't specify the syntax of a registry name; did
>> > >> you intend it to be a string?
>> >
>> > These have been changed to be symbols.
>>
>> Fine, but it appears that the new draft still doesn't say that.
>>
>> > >> Page 29 - *ALL-REGISTER-NAMES* -- a list of strings?
>> >
>> > Now a list of symbols.
>>
>> Again, the document doesn't say that.
p24,26,28,33: Right. I actually said they are 'names'. This may be
too general and can be changed to 'keyword symbols' without any
difficulty.
>>
>> That sounds good, but don't we also need the inverse function, to
>> construct a character object given a CCS and index?
>>
>> >
>> > That really depends on the definition of a conforming program. Is
>> > this defined yet?
>>
>> Never mind that; the real question is why do you want the standard to not
>> specify the meaning of tabs and form-feeds in source files?
>>
I don't have my CLtL with me but I don't think a meaning is given
to the semi-standard characters (unless we consider them self defining?)
>>
>> In the character table on page 17, do the "graphic labels" have any
>> significance? I don't see that the document uses them or requires them to
>> be used in any way. If not, that column should be deleted. I hope that
>> this is _not_ an example of what character names in a registry would look
>> like.
It is simply an assist in uniquely identifing each standard character
since glyphs can be ambigious.
>>
>> Your message of January 24 said you were going to:
>>
>> -- modify char-name, name-char, and #\name to accept character
>> names of the form 'registry:label'
>>
>> but I can't see that this draft does that. In particular, it is not at
>> all apparent how this is supposed to affect CHAR-NAME. Should I expect
>> (CHAR-NAME #\NEWLINE) to return "NEWLINE" or something like
>> "CONTROL:NEWLINE"? Are #\SPACE and #\NEWLINE to be the only characters
>> that can be referenced by a name that does not included a registry prefix?
>> Since all characters will have a label in some registry, does that mean
>> that CHAR-NAME will never return NIL anymore?
The form label:registry is given on p38 where for #\, "In particular,
an implementation may support names of the form label:registry."
It could do with repeating on p35 (name-char, char-name).
If a 'control' registry is standardized, I would expect these names
to replace (eventually) the various names now used. Some revision
of the Common Lisp standard might deprecate the current forms once
(if) a Character Registry standard is adopted.
∂02-Mar-89 1000 X3J13-mailer Re: cs proposal and straw vote
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:59:49 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA03605; Thu, 2 Mar 89 10:57:45 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA03241; Thu, 2 Mar 89 10:57:42 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903021757.AA03241@defun.utah.edu>
Date: Thu, 2 Mar 89 10:57:40 MST
Subject: Re: cs proposal and straw vote
To: baggins@ibm.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: Dan L. Pierson <pierson@mist.encore.com>, Wed, 01 Mar 89 15:49:59 EST
I pretty much agree with the points Dan raised. I generally support
(with varying degrees of enthusiasm) all of the subissues except the
last one, dealing with character registries.
My major complaints at this point are:
- I also don't feel that I could vote for the document in its current
form. At the very least, there should be some kind of cross-reference
indicating which parts of the document correspond to which of the
subissues you've identified, so that we know exactly what language
we are voting on for each of them. And, I would still like to see
a rationale presented for each of the subissues.
- I really believe it would be premature to standardize on the idea of
character registries at this time. I don't think that the idea is
inherently bad and awful, but given that the specifics of the proposal
do not appear to have stabilized and nobody has implemented it yet, I
think we would be running an unacceptable risk of standardizing the
wrong thing.
A few other nits:
I'm confused about what happens to the STRING-CHAR type. There is a
definition for it on page 22 but on the bottom of page 23 it is
removed from the table of standard type specifiers. And, which
subissue would removing it fall under? It's not mentioned in any of
the ones you list.
On page 28, it says: "There may be unassigned codes between 0 and
char-code-limit which are not legal arguments to code-char." Don't
you really mean to say "... for which code-char returns NIL"?
Why do we need CHAR-CODE-LIMIT, CODE-CHAR, and CHAR-CODE anyway?
While bits and fonts were in the standard, these were useful for
things like creating a character with the same code but different bits
or font attributes, but now that's out. If we want a function to use
for hashing characters, that's what CHAR-INT is for. The only other
use I can think of is supporting iteration over characters, and it
seems like this could be extremely inefficient in implementations that
support user-defined character sets. (In such a case, I would imagine
that one would make CHAR-CODE-LIMIT correspond to the limit imposed by
the representation, perhaps the same as MOST-POSITIVE-FIXNUM, but in
actual practice, very few of those codes would have corresponding
characters.) I agree with Dan that we'd be better off having a
specialized iterator.
Should we consider extending MAKE-STRING-OUTPUT-STREAM to take an
:ELEMENT-TYPE keyword?
-Sandra
-------
∂02-Mar-89 0905 X3J13-mailer Section 2.2 - part 5
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:05:12 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05377; Thu, 2 Mar 89 09:03:02 PST
Message-Id: <8903021703.AA05377@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA05377; Thu, 2 Mar 89 09:03:02 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Mar 89 07:42
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.2 - part 5
%% 2.8.0 1
\beginsubsubsection{\datatype Package}
An {\word object} of type {\datatype package} (a {\datatype package})
is a namespace that holds collections
of {\datatype symbols\/}.
%% 10.0.0 7
%% 11.0.0 4
A {\datatype package} is a data structure
that establishes a mapping from print
names to {\datatype symbols}.
At any given time one
{\datatype package}
is current. The current {\datatype package} is
the one that is the
value of @var[package]\rm. It is possible to refer to
{\datatype symbols} in
{\datatype packages}
other than the current one through the use of
package qualifiers in the representation of the {\datatype symbol}.
%% 11.0.0 5
The mappings in a {\datatype package} are divided
into two classes, external and internal. The
{\datatype symbols} accessible via these different mappings are
called external and
internal {\datatype symbols}
of the {\datatype package}. Within a
{\datatype package},
a print name refers to one {\datatype symbol} or to none; if it does refer
to a {\datatype symbol}, then it is either external or internal in that
{\datatype package}, but not both.
%% 11.0.0 6
External {\datatype symbols} are part of the package's public interface to other
{\datatype packages}.
{\datatype Symbols} become external
if they appear in {\function export}.
%% 11.0.0 7
A {\datatype symbol}
will always have the same
print name no matter what {\datatype package}
it appears in, but it may be external in some {\datatype
packages}
and internal in others.
A {\datatype symbol}
will not necessarily always have the same
printed representation because of the presence of package qualifiers ({\tt
:} and {\tt ::}).
%% 11.0.0 9
{\datatype Packages}
may be built up in layers. From the point of view of a
{\datatype package's} user,
the {\datatype package} is a single collection of mappings from
{\datatype strings} into internal and external {\datatype symbols}.
However, some of these
mappings may be established within the package itself, while other
mappings are inherited from other packages via {\function use-package}.
A {\datatype symbol} is
accessible in a {\datatype package} if it can be referred to
without a package qualifier when that {\datatype package} is current,
regardless of whether the mapping occurs within
that {\datatype package}
or via inheritance. A {\datatype symbol} is
present in a {\datatype package}
if the mapping is in the {\datatype package} itself and is
not inherited from somewhere else.
%% 5.1.2 6
%% 11.3.0 5
The {\datatype package}
named @f[keyword] contains all keyword {\datatype symbols}
used by the
@clisp\ system and by user-written code. Such {\datatype symbols} must be
easily accessible from any {\datatype package};
name conflicts are not an issue
because these {\datatype symbols\/}
are used only as labels, not to carry package-specific
attributes.
When a {\datatype symbol} is added to the @f[keyword] package, it
is made external, declared to be a constant, and is
made to
have itself as its value.
%% 11.0.0 19
Each {\datatype package} has a name (a {\datatype string})
and perhaps some nicknames. These
are assigned when the {\datatype package} is created
and can be changed
later.
%% 11.0.0 20
There is a single namespace for {\datatype packages}.
The function @Funref[find-package] translates a package
name or nickname into the
associated {\datatype package}.
The function @Funref[package-name] returns the name of a
{\datatype package}.
The function @Funref[package-nicknames] returns a {\datatype list} of all
nicknames for a {\datatype package}.
@Funref[rename-package] removes a
{\datatype package's}
current name and nicknames and replaces them with new ones
specified by the caller.
%% 11.0.0 35
{\datatype Symbols} from one {\datatype package}
may be made accessible in another {\datatype package} in
two ways.
%% 11.0.0 36
\beginlist
\itemitem{--}
Any individual {\datatype symbol}
may be added to a {\datatype package} by use
of @Funref[import]\rm. After the call to
{\function import}
it is possible to refer to the {\datatype symbols}
in the importing package
without any qualifier. The status of the {\datatype symbol}
in the {\datatype package}
it came from
is unchanged, and home package
for
this {\datatype symbol } is unchanged.
Once imported, a {\datatype symbol} is present in the
importing package
and can be removed only by calling {\function unintern}.
%% 11.4.0 4
A {\datatype symbol} is shadowed by another {\datatype symbol} in
some {\datatype package}
if the first {\datatype symbol} would be accessible by inheritance
if not for the presence of the second {\datatype symbol}.
The function @Funref[shadowing-import] causes the first {\datatype symbol}
to be imported without error
even if the second {\datatype symbol} is accessible.
%% 11.4.0 39
%% 11.4.0 40
\itemitem{--}
The second mechanism for making symbols from one package accessible in another
is provided by @Funref[use-package]\rm.
The function {\function unuse-package}
undoes the effects of a previous {\function use-package}.
\endlist
%% 11.4.0
There is no way to inherit the internal {\datatype symbols}
of another {\datatype package};
to refer to an internal {\datatype symbol},
the {\datatype symbol's} home
package must be made current,
a qualifier must be used, or the {\datatype symbol}
must be imported into the current
{\datatype package}.
%% 11.4.0 8
When a {\datatype symbol} is to be located in a
given {\datatype package}
the following occurs:
\beginlist
\itemitem{--} The {\datatype symbol} is looked for among the external and
internal {\datatype symbols} of the
{\datatype package} itself.
\itemitem{--} The
external {\datatype symbols} of the used {\datatype packages} are looked through
in some unspecified order. The
order does not matter; see the rules for handling name
conflicts listed below.
\endlist
%% 11.0.0 46
Within one {\datatype package}
any particular print name can refer to at most
one {\datatype symbol}. A name conflict
is said to occur when there is more than one candidate {\datatype symbol}.
Any time
a name conflict is about to occur,
a continuable error is signalled.
The following rules apply to name conflicts:
%% 11.0.0 47
\beginlist
%% 11.0.0 49
\itemitem{--}
Name conflicts are detected when they become possible, that is, when the
package structure is altered. Name
conflicts are not checked for during every name lookup.
\itemitem{--}
If the same {\datatype symbol}
is accessible to a {\datatype package} through more than
one path, there is no name conflict.
The same identical {\datatype symbol} cannot conflict with itself.
Name conflicts occur only between distinct {\datatype symbols} with
the same print name.
%% 11.0.0 48
\itemitem{--} Every {\datatype package} has a
list of shadowing {\datatype symbols}.
A shadowing {\datatype symbol} takes precedence over any
other {\datatype symbol} of the same print name
that would otherwise be accessible in the
{\datatype package}.
A name conflict involving a shadowing symbol is always
resolved in favor of the shadowing {\datatype symbol},
without signalling an error
(except for one exception involving {\function import}).
See @Funref[shadow] and @Funref[shadowing-import]\rm.
%% 11.0.0 50
\itemitem{--}
The functions {\function use-package}, {\function import}, and {\function export}
check for name
conflicts.
%% 11.0.0 52
\itemitem{--}
{\function shadow} and {\function shadowing-import}
never signal a name-conflict error.
%% 11.0.0 53
\itemitem{--}
{\function unuse-package}, {\function unexport}, and {\function unintern}
(when the {\datatype symbol}
being
uninterned is not a shadowing symbol) do not need to do any
name-conflict checking.
%% 11.0.0 54
\itemitem{--}
Giving a shadowing symbol to {\function unintern}
can uncover a name conflict that had
previously been resolved by the shadowing.
%% 11.0.0 55
\itemitem{--}
Aborting from a name-conflict error leaves the original {\datatype symbol}
accessible.
\itemitem{--}
Package functions signal name-conflict errors before making any
change to the package structure. When multiple changes are to be made,
it is
permissible for the implementation to process each change separately,
so that aborting from a name
conflict caused by the second {\datatype symbol}
in the {\datatype list} will not unexport the
first {\datatype symbol} in the {\datatype list}.
Multiple changes could be made with {\function export}.
%% 11.0.0 56
\itemitem{--}
Continuing from a name-conflict error should offer the user a chance to
resolve the name conflict in favor of either of the candidates. The
{\datatype package}
structure should be altered to reflect the resolution of the
name conflict, via {\function shadowing-import},
{\function unintern}, or {\function unexport}.
%% 11.0.0 57
\itemitem{--}
A name conflict in {\function use-package}
between a {\datatype symbol} directly present in the
using {\datatype package}
and an external {\datatype symbol} of the used
{\datatype package} is resolved
in favor of the first {\datatype symbol}
by making it a shadowing {\datatype symbol}, or in favor
of the second {\datatype symbol}
by uninterning the first {\datatype symbol} from the using
{\datatype package}.
%% 11.0.0 60
\itemitem{--}
A name conflict in {\function export} or {\function unintern}
due to a {\datatype package's}
inheriting two distinct {\datatype symbols}
with the same print name from two other
{\datatype packages}
may be resolved in favor of either {\datatype symbol} by importing it into
the using {\datatype package}
and making it a shadowing symbol, just as with
{\function use-package}.
\endlist
%% 11.2.0 5
Figure {\chapno--\the\capno}
lists the {\word tools} that are applicable
to {\datatype packages}.
For the {\word operators} listed here, all optional arguments named
{\arg package} default to the current value of @var[package]\rm. Where an
{\word operator}
takes an argument that is either a {\datatype symbol} or a {\datatype list}
of {\datatype symbols},
an argument of @false\ is treated as an empty {\datatype list} of
{\datatype symbols}. Any {\arg package}
argument may be either a {\datatype string}, a {\datatype symbol}, or
a {\datatype package}.
If a {\datatype symbol}
is supplied, its print name will be used as the {\datatype package}
name.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
@var[package] & {\tt make-package} & {\tt in-package} \cr
{\tt find-package }&{\tt package-name }&{\tt package-nicknames }\cr
{\tt rename-package }&{\tt package-use-list }&{\tt package-used-by-list }\cr
{\tt package-shadowing-symbols }&{\tt list-all-packages }&{\tt intern }\cr
{\tt find-symbol }&{\tt unintern }&{\tt export }\cr
{\tt unexport }&{\tt import }&{\tt shadowing-import }\cr
{\tt shadow }&{\tt use-package }&{\tt unuse-package }\cr
{\tt find-all-symbols }&{\tt do-symbols }&{\tt do-external-symbols }\cr
{\tt do-all-symbols }&{\tt modules }&{\tt provide }\cr
{\tt require }& & \cr
\noalign{\vskip -9pt}
}}
\caption{Package tools}
\endfig
%% 11.6.0 1
The following packages, at least, are built into every @clisp\ system:
%% 11.6.0 2
\beginlist
\itemitem{\tt lisp}
%% clean-up issue `contains all and only'
The package named @f[lisp] contains the primitives of the
@clisp\ system. Its external symbols include all of the
user-visible functions and global variables that are present in the
@clisp\ system, such as {\function car}, {\function cdr}, @var[package]\rm, etc.
%% 11.6.0 3
\itemitem{\tt user}
%% clean-up issue `lisp package and may use other packages as well'
The @f[user] package is the value of @var[package] when
a @clisp\ system starts up. This package uses the @f[lisp] package.
%% 11.6.0 4
\itemitem{\tt keyword}
This package contains all of the keywords used by built-in
or user-defined @xlisp\ functions. Printed symbol representations
that start with a colon are interpreted as referring to symbols
in this package, which are always external symbols. All symbols in this
package are treated as constants that evaluate to themselves.
The function {\function symbol-value} may be used to retrieve these values.
%% 11.6.0 5
\itemitem{\tt system}
This package name is reserved to the implementation,
uses the @f[lisp] package, and has the
nickname @f[sys]\rm.
\endlist
\beginsubsubsection{\datatype Pathname}
%% 23.1.1 1
All file systems dealt with by @clisp\ are forced into a common framework
in which files are named by an object of type {\datatype pathname},
a {\datatype pathname},
that can be translated by the underlying operating system to a file
name.
%% 23.1.1 3
A {\datatype pathname} always has six components, described below.
These components
are the common interface that allows programs to work the same way with
different file systems; the mapping of the pathname components into the
concepts peculiar to each file system is
implementation-dependent.
%% 23.1.1 4
\beginlist
%% 23.1.1 5
%% 23.1.1 17
\itemitem{\bf Host}
The name of the file system on which the file resides.
The host may be a
{\datatype string}, indicating a file system, or a
{\datatype list}
of {\datatype strings},
of which the first names the file system and the rest
may be used for inter-network routing.
\itemitem{\bf Device}
Corresponds to the ``device'' or ``file structure'' concept in many
host file systems: the name of a (logical or physical) device containing files.
%% 23.1.1 6
\itemitem{\bf Directory}
Corresponds to the ``directory'' concept in many host file systems:
the name of a group of related files.
%% 23.1.1 7
\itemitem{\bf Name}
The name of a group of files that can be thought of as
conceptually the ``same'' file.
%% 23.1.1 8
%% 23.1.1 15
\itemitem{\bf Type}
Corresponds to the ``filetype'' or ``extension'' concept in many host
file systems. This says what kind of file this is.
The type is always a {\datatype string}, @nil\ or {\keyword :wild}.
When the type is not supplied, its value is implementation-dependent.
%% 23.1.1 9
%% 23.1.1 16
\itemitem{\bf Version}
Corresponds to the ``version number'' concept in many host file systems.
The version is either a positive {\datatype integer}
or a {\datatype symbol } from the following list:
{\function nil}, {\keyword :wild}, or
{\keyword :newest} (refers to the largest version number
that already exists in the file system when reading a file, or to
a version number
greater than any already existing in the file system
when writing a new file). Implementations
may define other special version {\datatype symbols}.
\endlist
The following rules apply to the components of a {\datatype pathname}.
%% 23.1.1 12
\beginlist
\itemitem{--}
Not all of the components of a {\datatype pathname}
need to be supplied. If a
component of a {\datatype pathname}
is missing, its value is @nil\rm. Before the file
system interface can do anything with a file, such as opening the
file, all the missing components of a {\datatype pathname} must be filled in
from a set of defaults.
Parsing a namestring
that does not contain certain components will result in a
{\datatype pathname} with
missing components.
%% 23.1.1 13
\itemitem{--}
A component of a {\datatype pathname} can also be the keyword {\keyword
:wild},
which means that the {\datatype pathname}
component matches anything.
%% 23.1.1 14
\itemitem{--}
Except where otherwise specified, the values
for components of a {\datatype pathname} are
implementation-dependent.
%% 23.1.1 18
\itemitem{--}
The device, directory, and name components can each be a {\datatype string}
(with
implementation-dependent rules on allowed characters and length) or possibly
some other @clisp\ {\word object}
which has an implementation-dependent format.
Supplying a {\datatype string}
as a pathname component for a host that requires an {\word object} as a
component will cause conversion of the {\datatype string} to the appropriate
{\word object}.
\endlist
%% 23.1.1 10
A {\datatype pathname}
is not necessarily the name of a specific file.
Rather, it is a specification (possibly only a partial specification) of
how to access a file.
A {\datatype pathname}
need not correspond to any file that
actually exists, and more than one {\datatype pathname}
can refer to the same file.
For example, the {\datatype pathname}
with a version of {\keyword :newest} may refer to the
same file as a {\datatype pathname}
with the same components except a certain number
as the version. Indeed, a {\datatype pathname}
with version {\keyword :newest} may refer to
different files as time passes, because the meaning of such a {\datatype
pathname}
depends on the state of the file system.
%% 23.1.1 11
{\datatype Pathnames} that are specified by {\datatype strings}
(called namestrings) are parsed and
merged. Parsing is the conversion of a namestring
into a {\datatype pathname}. This operation is
implementation-dependent, because the format of namestrings
is implementation-dependent.
Merging takes a {\datatype pathname} with missing components
and supplies values for those components from a source of defaults.
%% 23.1.1 20
An implementation is free to accommodate other file system features in its
{\datatype pathname} representation and provide a parser that can process such
specifications in namestrings. A program that
depends explicitly on any such features will not be portable.
The following figures contain lists of {\word tools} that are applicable to the
file system interface.
Figure {\chapno--\the\capno} lists the {\datatype pathname} {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt pathname }&{\tt truename }&{\tt parse-namestring }\cr
{\tt merge-pathnames }& @var[default-pathname-defaults]&{\tt make-pathname }\cr
{\tt pathnamep }&{\tt pathname-host }&{\tt pathname-device }\cr
{\tt pathname-directory }&{\tt pathname-name }&{\tt pathname-type }\cr
{\tt pathname-version }&{\tt namestring }&{\tt file-namestring }\cr
{\tt directory-namestring }&{\tt host-namestring }&{\tt enough-namestring }\cr
{\tt user-homedir-pathname } & & \cr
\noalign{\vskip -9pt} }}
\caption{File System Interface tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the file and directory {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt directory} &{\tt open }&{\tt with-open-file }\cr
{\tt rename-file }&{\tt delete-file }&{\tt probe-file }\cr
{\tt file-write-date }&{\tt file-author }&{\tt file-position }\cr
{\tt file-length} & {\tt load} & @var[load-verbose] \cr
\noalign{\vskip -9pt} }}
\caption{File System Interface tools - 2}
\endfig
%% 2.11.0 1
\beginsubsubsection{\datatype Random-state}
An {\word object} of type {\datatype random-state} (a {\datatype random-state}
object)
contains state information used by the pseudo-random number generator.
%% 12.9.0 1
The pseudo-random numbers
in a random number series are implementation-dependent,
but the distribution of the numbers should
be machine-independent.
Figure {\chapno--\the\capno} lists
the {\word tools} that are applicable to {\datatype random-state}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt random} & @var[random-state] & \cr
{\tt make-random-state} & {\tt random-state-p} & \cr
\noalign{\vskip -9pt}
}}
\caption{Random-state tools}
\endfig
\issue{FUNCTION-TYPE:X3J13-MARCH-88}
\beginsubsubsection{\datatype Function}
An {\word object} of type {\datatype function\/} is called a {\datatype
function}.
A {\datatype function}
may be supplied as an argument without error to @Funref[funcall]
or @Funref[apply]\rm, and is
to be executed as code when arguments are supplied.
The functional computation produces one or more values, produces no
values, or
takes a non-local exit.
The type {\datatype function} has at least one {\word subtype} called
{\datatype compiled-function}.
Implementations are free to define other {\word subtypes} of
the type {\datatype function}.
\beginsubsubsection{\datatype Compiled-function}
An object of type {\datatype compiled-function} is a called a {\datatype
compiled-function}.
%% 2.13.0 2
A {\datatype compiled-function} is a compiled code {\word object}
that has been produced by the
compiler.
\endissue{FUNCTION-TYPE:X3J13-MARCH-88}
\beginsubsubsection{\datatype Nil}
The empty data type, which contains no {\word objects}, is
denoted by @nil\rm.
\beginsubsubsection{\datatype Common}
The type {\datatype common} encompasses all the
{\word objects} required by the @clisp\ language. An implementation
is free to provide other
{\word types} that are not {\word subtypes} of the type {\datatype common}.
\endsubSection%{Data Type Definition}
%% Type Specifiers
\beginsubSection{Type Specifiers}
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
The following will be deleted:
%% 4.5.0 5
Type specifiers are used for two different purposes:
declaration and discrimination.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
There are two reasons that an {\word object}'s type is used:
\beginlist
\itemitem{1.} The consequences are undefined if an
{\word object} is an argument to an {\word operator}
and the argument
is not one of the {\word operator}'s required {\word types}.
\itemitem{2.} If run-time optimizations in compiled code are desired,
it is often necessary to reduce the number of {\word types} of {\word objects}
a variable can hold.
\endlist
%% 4.1.0 1
The type specifiers (they are {\datatype symbols})
defined by the system are those shown in Figure
{\chapno--\the\capno}.
%% 4.3.0 4
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt array}&{\tt integer}&{\tt short-float}\cr
{\tt atom}&{\tt keyword}&{\tt signed-byte}\cr
{\tt bignum}&{\tt list}&{\tt simple-array}\cr
{\tt bit}&{\tt long-float}&{\tt simple-bit-vector}\cr
{\tt bit-vector}&{\tt mod}&{\tt simple-string}\cr
{\tt character}&{\tt nil}&{\tt simple-vector}\cr
{\tt common}&{\tt null}&{\tt single-float}\cr
{\tt compiled-function}&{\tt number}&{\tt standard-char}\cr
{\tt complex}&{\tt package}&{\tt stream}\cr
{\tt cons}&{\tt pathname}&{\tt string}\cr
{\tt double-float}&{\tt random-state}&{\tt string-char}\cr
{\tt fixnum}&{\tt ratio}&{\tt symbol}\cr
{\tt float}&{\tt rational}&{\tt t}\cr
{\tt function}&{\tt readtable}&{\tt unsigned-byte}\cr
{\tt hash-table}&{\tt sequence}&{\tt vector}\cr
\noalign{\vskip -9pt} }}
\caption{Table of Atomic Type Specifiers}
\endfig
The syntax for type specifiers is illustrated in Figure {\chapno--\the\capno}.
\boxfig
{\advance\baselineskip by 2.5pt
\halign{\hskip\leftskip\hfil#&#\hfil\cr
{\it typespec\/}::$=\;$&{\it atomic-type-specifier\/}\cr
$\vert\;$& \paren {{\tt satisfies} predicate-name\/}\cr
$\vert\;$& \paren {{\tt member} \star{\curly{object}}}\cr
$\vert\;$& \paren {{\tt not} typespec\/}\cr
$\vert\;$& \paren {{\tt and} \star{\curly{typespec}}}\cr
$\vert\;$& \paren {{\tt or} \star{\curly{typespec}}}\cr
$\vert\;$& \paren {{\tt array} {\ttbrac{\curly{typespec $\vert$ {\tt *} } \brac{dimensions}}}}\cr
$\vert\;$& \paren {{\tt simple-array} {\ttbrac{\curly{typespec $\vert$ {\tt *} } \brac{dimensions}}}}\cr
$\vert\;$& \paren {{\tt vector} {\ttbrac{\curly{typespec $\vert$ {\tt *} } \brac{\curly{size $\vert$ {\tt *}}}}}}\cr
$\vert\;$& \paren {{\tt simple-vector} \ttbrac{\it size\/}}\cr
$\vert\;$& \paren {{\tt string} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt simple-string} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt bit-vector} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt simple-bit-vector} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt integer} \ttbrac{integer-limit \brac{integer-limit}}}\cr
$\vert\;$& \paren {{\tt fixnum} \ttbrac{fixnum-limit \brac{fixnum-limit}}}\cr
$\vert\;$& \paren {{\tt mod} \ttbrac{\it integer\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt signed-byte} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt unsigned-byte} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt rational} \ttbrac{rational-limit \brac{rational-limit}}}\cr
$\vert\;$& \paren {{\tt float} \ttbrac{float-limit \brac{float-limit}}}\cr
$\vert\;$& \paren {{\tt short-float} \ttbrac{short-float-limit \brac{short-float-limit}}}\cr
$\vert\;$& \paren {{\tt single-float} \ttbrac{single-float-limit \brac{single-float-limit}}}\cr
$\vert\;$& \paren {{\tt double-float} \ttbrac{double-float-limit \brac{double-float-limit}}}\cr
$\vert\;$& \paren {{\tt long-float} \ttbrac{long-float-limit \brac{long-float-limit}}}\cr
$\vert\;$& \paren {{\tt complex} \ttbrac{typespec $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt function} \ttbrac{arg-typespec-list \brac{value-typespec}}}\cr
}}
\caption{Syntax for Type Specifiers}
\endfig
Figure {\chapno--\the\capno} gives the definitions
applicable to the syntax for type specifiers.
\boxfig
{\advance\baselineskip by 2.5pt
\halign{#\hfil&#\hfil\cr
{\it arg-typespec-list\/}::$=$ \vtop{\hbox{\star{(\curly{typespec}}
\ttbrac{{\opt} {\star{\curly{typespec\/}}}}
\ttbrac{{\rest} {\it typespec\/}}
\hbox{\quad\ttbrac{{\key{}} \star{\curly{\it typespec\/}}}{\rm )}}}} & \cr
{\it value-typespec\/}::$=$ {\it typespec\/} $\vert$ \paren{{\tt values} . {\it arg-typespec-list\/}} & \cr
{\it dimensions\/}::$=$ {\it integer\/} $\vert$ {\tt *} $\vert$
\paren{\star{\curly{integer $\vert$ {\tt *} }}} & \cr
{\it size\/}::$=$ {\it integer\/} & \cr
{\it integer-limit\/}::$=$ {\it integer\/} $\vert$ {\tt *}
$\vert$ ({\it integer\/}) & \cr
{\it fixnum-limit\/}::$=$ {\it fixnum\/} $\vert$ {\tt *}
$\vert$ ({\it fixnum\/}) &\cr
{\it rational-limit\/}::$=$ {\it rational\/} $\vert$ {\tt *} $\vert$ ({\it rational\/})\cr
{\it float-limit\/}::$=$ {\it float\/} $\vert$ {\tt *} $\vert$ ({\it float\/})\cr
{\it short-float-limit\/}::$=$ {\it short-float\/} $\vert$ {\tt *} $\vert$ ({\it short-float\/})\cr
{\it single-float-limit\/}::$=$ {\it single-float\/} $\vert$ {\tt *} $\vert$ ({\it single-float\/})\cr
{\it double-float-limit\/}::$=$ {\it double-float\/} $\vert$ {\tt *} $\vert$ ({\it double-float\/})\cr
{\it long-float-limit\/}::$=$ {\it long-float\/} $\vert$ {\tt *} $\vert$ ({\it long-float\/})\cr
}}
\caption{Definitions for Syntax for Type Specifiers}
\endfig
%% 4.2.0 1
If a type specifier is a {\datatype list}, the {\word car}
of the {\datatype list}
is a {\datatype symbol}, and the rest of the {\datatype list}
is subsidiary
{\word type} information. The subsidiary items may be
unspecified. The unspecified subsidiary items are indicated
by writing @f[*]\rm. For example, to completely specify
a {\datatype vector}, the {\word type} of the elements
and the length of the {\datatype vector}, must be present.
@lisp
(vector double-float 100)
@endlisp
To leave the length unspecified:
@lisp
(vector double-float *)
@endlisp
To leave the element type unspecified:
@lisp
(vector * 100)
@endlisp
Suppose that two type specifiers are the same except that the first
has a @f[*] where the second has a more explicit specification.
Then the second denotes a {\word subtype}
of the {\word type} denoted by the first.
%% 4.2.0 2
If a {\datatype list}
has one or more unspecified items at the end, those items
may be dropped.
If dropping all occurrences of @f[*] results in a singleton {\datatype list},
then the parentheses may be dropped as well (the list may be replaced
by the {\datatype symbol} in its {\word car}).
For example,
{\tt (vector double-float *)}
may be abbreviated to {\tt (vector double-float)},
and {\tt (vector * *)} may be abbreviated to {\tt (vector)}
and then to
{\tt vector}.
A list of possible type specifier {\datatype lists} follows:
\beginlist
%% 4.3.0 1
\itemitem
{\tt (satisfies {\arg predicate-name})}
This denotes
the set of all {\word objects}
that satisfy the predicate {\arg predicate-name},
which must be a {\datatype symbol}
whose global {\word function} definition is a one-argument
predicate.
A name is required for {\arg predicate-name}; {\word lambda-expressions}
are not allowed.
For example, the type {\tt (satisfies numberp)} is the
same as the type {\datatype number}.
The call {\tt (typep x '(satisfies p))}
results in applying @f[p] to @f[x]
and returning @f[t] if the result is true and @nil\ if the result is false.
%% 4.3.0 2
For example, the type {\datatype string-char} could be defined as
@lisp
(deftype string-char () '(and character (satisfies string-char-p)))
@endlisp
%% 4.4.0 3
\itemitem
{\tt (member {\arg object1} {\arg object2} ...)}
This denotes the set
containing the named {\arg objects}. An {\word object} is of
this {\word type}
if and only if it is @Funref[eql] to one of the specified {\arg objects}.
%% 4.4.0 4
\itemitem
{\tt (not {\arg type})}
This denotes the set of all {\word objects} that
are not of the type {\arg type}.
%% 4.4.0 5
\itemitem{\tt (and {\arg type1} {\arg type2} ...)}
This denotes the set of all {\word objects} of the
{\word type} determined by the intersection of
{\arg type1}, {\arg type2},....
%% 4.4.0 7
\itemitem{\tt (or {\arg type1} {\arg type2} ...)}
This denotes the set of all {\word objects} of the
{\word type} determined the union of {\arg type1}, {\arg type2},....
For example, the type {\datatype list}
by definition is the same as
{\tt (or null cons)}. Also, the value
returned by
@Funref[position] is of type {\tt (or null (integer 0 *))}
(either @nil\ or a non-negative {\datatype integer}).
%% 4.6.0 3
\itemitem{\tt (integer {\arg low} {\arg high})}
This denotes the {\datatype integers} between
{\arg low} and {\arg high}. {\arg Low} and {\arg high}
must each be {\datatype integers}, a {\datatype list}
of an {\datatype integer}, or unspecified.
An {\datatype integer} is an inclusive limit,
a {\datatype list} of an {\datatype integer} is an exclusive limit, and
@f[*] means that a limit does not exist
and so effectively denotes minus or plus infinity, respectively.
{\datatype Fixnum} is a name
for {\tt (integer {\arg smallest} {\arg largest})}
for implementation-dependent
values of {\arg smallest} and {\arg largest}.
The type {\tt (integer 0 1)}
has the name {\datatype bit}.
%% 4.6.0 4
\itemitem{\tt (mod {\arg n})}
This denotes the set of non-negative {\datatype integers} less than {\arg
n}.
This is equivalent to {\tt (integer 0 {\it n}-1)}
or to {\tt (integer 0 ({\it n}))}.
%% 4.6.0 5
\itemitem{\tt (signed-byte {\arg s})}
This denotes the set of {\datatype integers} that can be represented
in two's-complement form in a byte of {\arg s} bits. This is
equivalent to
{\tt (integer $-2↑{s-1} 2↑{s-1}-$1)}.
The type {\datatype signed-byte} or the type {\tt (signed-byte *)}
is the same as the type {\datatype integer}.
%% 4.6.0 6
\itemitem{\tt (unsigned-byte {\arg s})}
This denotes the set of non-negative {\datatype integers} that can be
represented in a byte of {\arg s} bits. This is equivalent to
{\tt (mod $2↑s$)},
that is, {\tt (integer 0 $2↑s-$1)}.
The type {\datatype unsigned-byte} or
the type {\tt (unsigned-byte *)} is the same as
the type {\tt (integer 0 *)}, the set of non-negative {\datatype integers}.
%% 4.6.0 7
\itemitem{\tt (rational {\arg low} {\arg high})}
This denotes the {\datatype rationals} between
{\arg low} and {\arg high}. {\arg Low} and {\arg high}
must each be a {\datatype rational}, a {\datatype list} of a {\datatype
rational}, or unspecified.
A {\datatype rational} is an inclusive limit,
a {\datatype list} of a {\datatype rational} is an exclusive limit, and
@f[*] means that a limit does not exist
and so denotes minus and plus infinity, respectively.
%% 4.6.0 8
%% 4.6.0 9
\itemitem{\tt (float {\arg low} {\arg high})}
\itemitem{\tt (short-float {\arg low} {\arg high})}
\itemitem{\tt (single-float {\arg low} {\arg high})}
\itemitem{\tt (double-float {\arg low} {\arg high})}
\itemitem{\tt (long-float {\arg low} {\arg high})}
These denote the set of {\datatype floating}-point numbers between
{\arg low} and {\arg high}. {\arg Low} and {\arg high}
must each be a {\datatype floating}-point number,
a {\datatype list} of a {\datatype floating}-point number,
or unspecified. A {\datatype floating}-point number
is an inclusive limit, a {\datatype list} of a
{\datatype floating}-point number is an exclusive limit, and
@f[*] means that a limit does not exist
and so denotes minus and plus infinity, respectively.
In the case of the types {\tt short-float}, {\tt single-float},
{\tt double-float}, or {\tt long-float},
if a limit is a {\datatype floating}-point
number (or a {\datatype list} of one),
it must be one of the appropriate format.
%% 4.6.0 10
\itemitem{\tt (string {\arg size})}
This denotes the same type as
the type {\tt (array string-char ({\arg size}))}:
the set of {\datatype strings} of size {\arg size}.
%% 4.6.0 11
\itemitem{\tt (simple-string size {\arg size})}
This denotes the same type
as the type {\tt (simple-array string-char ({\arg size}))}: the set of
{\datatype simple-strings} of size {\arg size}.
%% 4.6.0 12
\itemitem{\tt (bit-vector {\arg size})}
This denotes the same type as the type {\tt (array bit ({\arg size}))}:
the set of {\datatype bit-vectors} of size {\arg size}.
%% 4.6.0 13
\itemitem{\tt (simple-bit-vector {\arg size})}
This denotes the same type as the type
{\tt (simple-array bit ({\arg size}))}: the set of
{\datatype simple-bit-vectors} of size {\arg size}.
%% 4.5.0 6
%% 4.5.0 7
\itemitem{\tt (array {\arg element-type dimensions})}
This denotes the set
of {\datatype arrays\/}
whose elements are all of type {\arg element-type}
and whose dimensions are {\arg dimensions}.
{\arg Element-type} must be a valid type specifier or unsupplied.
{\arg Dimensions} must be a non-negative {\datatype integer},
which is the number
of dimensions, or a {\datatype list} of non-negative {\datatype integers}
representing the length of each dimension (any dimension
may be unsupplied instead), or it may be unsupplied.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
The following will be left out:
For declaration purposes, this {\word type} encompasses those
{\datatype arrays\/}
that can result by supplying {\arg element-type} as the element type
to the function @Funref[make-array]\rm; this may be different
from what the {\word type} means for discrimination purposes.
For example:
@lisp
(array integer 3) ;Three-dimensional arrays of integers
(array integer (* * *)) ;Three-dimensional arrays of integers
(array * (4 5 6)) ;4-by-5-by-6 arrays
(array character (3 *)) ;Two-dimensional arrays of characters that have
;three rows
(array short-float @empty) ;Zero-rank arrays of short-floats
@Endlisp
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
{\tt (array *)} refers to all {\datatype arrays\/}
regardless of element type, {\tt (array {\arg type-specifier})}
refers only to those {\datatype arrays\/}
that can result from giving {\arg type-specifier} as the
{\tt :element-type} argument to {\function make-array}.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
Note that the type {\tt (array t)}
is a subset of the type {\tt (array *)}.
The reason is that the type {\tt (array t)} is the set of {\datatype arrays\/}
that can
hold any {\word object} (the elements are of type
{\datatype t},
which includes all {\word objects}).
On the other hand, the type {\tt (array *)}
is the set of all {\datatype arrays\/} whatsoever, including for example
{\datatype arrays\/} that can hold only {\datatype characters}.
Now
the type {\tt (array character)} is not a subset of the type {\tt (array t)};
the two sets
are {\word disjoint} because the type {\tt (array character)} is not the
set of all {\datatype arrays\/} that can hold
{\datatype characters}, but rather the set of
{\datatype arrays\/}
that are specialized to hold precisely {\datatype characters} and no
other {\word objects}.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
The following will be deleted:
The following expression cannot be used to determine if
array @f[foo] can hold a {\datatype character}:
@lisp
(typep foo '(array character))
@endlisp
The following expression can be used to determine if
array @f[foo] can hold a {\datatype character}:
@lisp
(subtypep 'character (array-element-type foo))
@endlisp
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%% 4.5.0 8
\itemitem{\tt (simple-array {\arg element-type dimensions})}
This is equivalent
to the type {\tt (array {\arg element-type} {\arg dimensions})}
except that it additionally
specifies that the {\datatype array\/}
{\word objects} are {\datatype simple-arrays}.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
{\tt (simple-array *)} refers to all {\datatype simple-arrays\/}
regardless of element type, {\tt (simple-array {\arg type-specifier})}
refers only to those {\datatype simple-arrays\/}
that can result from giving {\arg type-specifier} as the
{\tt :element-type} argument to {\function make-array}.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%% 4.5.0 9
\itemitem{\tt (vector {\arg element-type} {\arg size})}
This denotes the set of specialized
one-dimensional {\datatype arrays\/}
whose elements are all of type {\arg element-type}
and whose lengths are size {\arg size}. This is equivalent to
the type {\tt (array {\arg element-type} ({\arg size}))}.
For example:
@lisp
(vector double-float) ;Vectors of double-format floating-point numbers
(vector * 5) ;Vectors of length 5
(vector t 5) ;General vectors of length 5
(vector (mod 32) *) ;Vectors of integers between 0 and 31
@Endlisp
The types {\tt (vector string-char)} and {\tt (vector bit)}
have the names {\datatype string} and {\datatype bit-vector}.
Every implementation of @clisp\ must provide distinct representations for
these as distinct specialized {\word types}.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
{\tt (vector *)} refers to all {\datatype vectors\/}
regardless of element type, {\tt (vector {\arg type-specifier})}
refers only to those {\datatype vectors\/}
that can result from giving {\arg type-specifier} as the
{\tt :element-type} argument to {\function make-array}.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%% 4.5.0 10
\itemitem{\tt (simple-vector {\arg size})}
This is the same
as the type {\tt (vector t {\arg
size})} except that it additionally specifies
that its elements are {\datatype simple-vectors}.
%% 4.5.0 11
\itemitem{\tt (complex {\arg type})}
Every element of this {\word type} is a
{\datatype complex\/} number whose real part
and imaginary part are each of type {\arg type}.
This {\word type} encompasses those
{\datatype complex\/} numbers
that can result by giving numbers of the specified {\word type}
to @Funref[complex]\rm.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
The following will be deleted:
This may be different
from what the {\word type} means for discrimination purposes.
For example, Gaussian integers might be
described as the type {\tt (complex integer)}, even in implementations
where giving two {\datatype integers} to {\function complex\/} results
in an {\word object} of type {\tt (complex rational)}.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%% 2.1.4 3
The type of a specific {\datatype complex\/} number is indicated by a list
of the word @f[complex] and the type of the components; for example,
a specialized representation for {\datatype complex\/}
numbers with {\datatype short-float}
parts would be of type {\tt (complex short-float)}. The type
{\datatype complex\/}
encompasses all complex representations.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
{\tt (typep {\arg object} '(complex {\arg type-specifier}))}
refers to all {\datatype complex\/} numbers that can result from
giving {\datatype numbers} of type {\arg type-specifier}
to the function {\function complex\/}, plus all other
{\datatype complex\/} numbers
of the same specialized representation.
Both the real and the imaginary parts of any such
{\datatype complex\/} number must
satisfy:
{\tt (typep {\arg realpart}|{\arg imagpart} '{\arg type-specifier})}
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%% 4.5.0 12
\itemitem{\tt (function ({\arg arg1-type} {\arg arg2-type} ...)
{\arg value-type})}
\issue{FUNCTION-TYPE}
The list form of the type {\datatype function}
may be used only for declaration and not for discrimination.
\endissue{FUNCTION-TYPE}
Every element of this {\word type} is
a {\word function} that accepts arguments at least of the
types
specified by the {\arg argj-type} forms and returns a value that is a
member of the types specified by the {\arg value-type} form. The
@optional, @rest, @key,
\issue{FUNCTION-TYPE-KEY-NAME}
and @allowotherkeys\
\endissue{FUNCTION-TYPE-KEY-NAME}
markers may appear in the list of argument
types.
\issue{FUNCTION-TYPE-KEY-NAME}
The @key\ parameters
should be supplied as lists of the form {\tt (keyword type)}.
The {\tt keyword} must
be a valid keyword-name
symbol and must be supplied in the actual arguments of a
call. This is usually a {\datatype symbol} in the {\tt keyword} package
but can be any {\datatype symbol}.
The @allowotherkeys\ declarations are interpreted as follows:
when @key\ is given in a
{\tt function} type specifier lambda list,
it is safe to assume that the @key s given
are exhaustive unless @allowotherkeys\ is present.
@allowotherkeys\ is an indication
that other keyword arguments may actually be
supplied and, if supplied, may be used.
For example,
the type of the function {\function make-list} could be declared as:
@lisp
(function make-list ((integer 0) &key (:initial-element t)) list)
@endlisp
\endissue{FUNCTION-TYPE-KEY-NAME}
The {\arg value-type} may be a {\tt values}
type specifier in order to indicate the
{\word types} of multiple values.
%% 4.5.0 13
For example, the function @Funref[cons] is of type
{\tt (function (t t) cons)},
because it can accept any two arguments and always returns a {\word
cons}.
{\function cons} is
also of type {\tt (function (float string) list)},
because it can
accept a {\datatype floating}-point number
and a {\datatype string} (among other things), and its
result is always of type {\datatype list}
(in fact a {\word cons} is never {\datatype null},
but that does not matter for this type declaration).
@Funref[truncate] is of type
{\tt (function (number number) (values number number))},
as well as of type
{\tt (function (integer (mod 8)) integer)}.
%% 4.5.0 14
\itemitem{\tt (values {\arg value1-type} {\arg value2-type} ...)}
This type specifier may be used only
as the {\arg value-type} in a {\tt function} type specifier or in
@Specref[the]\rm. It is used to specify individual {\word types} when
multiple values are involved.
The
@optional, @rest, and @key\ markers may appear in the {\arg value-type} list;
they indicate the parameter list of a
{\word function} that,
when given to @Specref[multiple-value-call] along with
the values, would be suitable for receiving those values.
\endlist
%% 4.7.0 1
New type specifiers can come into existence in two ways.
\beginlist
\itemitem{\bull} Defining a structure or class
with @Macref[defstruct] or {\function defclass} automatically
causes the name of the structure or class to be a new type specifier
{\datatype symbol}.
\itemitem{\bull} {\function deftype} can be used to define new type specifier
abbreviations.
\endlist
Figure {\chapno--\the\capno}
lists the {\word tools} that are applicable to types and declarations.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt deftype }&{\tt coerce }&{\tt type-of }\cr
{\tt declare }&{\tt locally }&{\tt proclaim }\cr
{\tt the }&{\tt defstruct }&\cr
\noalign{\vskip -9pt} }}
\caption{Type and declaration tools}
\endfig
\beginsubsubsection{Type Upgrading}
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
When type specifiers are used to declare {\word objects} to be of a certain
{\word type}, they are said to be used
for declaration. A type specifier used for declaration
can be the
{\tt :element-type} argument to
{\function make-array}, the {\arg result-type}
argument to {\function coerce},
an argument to the special form {\function the},
or an argument to {\function declare}.
An {\word object} declared to be of a certain
{\word type} may not satisfy
{\function typep} with that type specifier.
This is permissible because an implementation
is required only to construct the
result out of the most specialized {\word type} that can
accommodate elements of the {\word type} supplied as the argument
to the {\tt :element-type} named argument to {\function make-array}.
That is, an implementation may only provide a
very small number of {\word types} for storing
{\datatype arrays\/},
and it is permitted to upgrade any {\word type} request into
one of its built-in repertoire.
One type specifier with
this property is {\tt (array {\arg type-specifier})}
for various implementation-dependent values of {\arg type-specifier}.
Another type specifier with this property is
{\tt (complex {\arg type-specifier})}.
{\word Type} upgrading implies a movement upwards in the type
hierarchy lattice. In the case of {\datatype arrays\/}
the {\arg type-specifier} must be
a {\word subtype} of
{\tt (upgraded-array-element-type '{\arg type-specifier})}.
In the case of {\datatype complex\/} numbers, the
{\arg type-specifier} must be a {\word subtype} of
{\tt (upgraded-complex-part-type {\arg type-specifier})}.
If {\arg type-specifier1} is a {\word subtype} of {\arg type-specifier2}, then
{\tt (upgraded-array-element-type '{\arg type-specifier1})}
must also be a {\word subtype} of
{\tt (upgraded-array-element-type '{\arg type-specifier2})}.
Two {\word disjoint types} can be upgraded into
the same thing.
See {\function array-element-type}.
Upgrading an {\datatype array\/} element {\word type} is independent of any
other property of {\datatype arrays\/},
such as {\word rank}, adjustability, {\word fill-pointers}, or
displacement.
The reason {\word rank} is included is because
it would not be consistently possible to displace {\datatype arrays\/}
to those of
differing {\word rank} if {\word rank} were not included.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
\endsubsubsection%{Type Upgrading}
\endsubSection%{Type Specifiers}
∂02-Mar-89 1151 X3J13-mailer Re: cs proposal comments
Received: from ti.com by SAIL.Stanford.EDU with TCP; 2 Mar 89 11:51:39 PST
Received: by ti.com id AA08145; Thu, 2 Mar 89 13:50:34 CST
Received: from Kelvin by tilde id AA05068; Thu, 2 Mar 89 13:39:29 CST
Message-Id: <2813859524-5211323@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 2 Mar 89 13:38:44 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Thom Linden <baggins@IBM.com>
Cc: x3j13@sail.stanford.edu
Subject: Re: cs proposal comments
In-Reply-To: Msg of Thu, 02 Mar 89 02:20:21 PST from Thom Linden <baggins@IBM.com>
> >> Never mind that; the real question is why do you want the standard to not
> >> specify the meaning of tabs and form-feeds in source files?
> >>
> I don't have my CLtL with me but I don't think a meaning is given
> to the semi-standard characters (unless we consider them self defining?)
I'm talking about page 336 of CLtL which specifies that the reader treats
#\TAB and #\PAGE as whitespace. Section A.22.1.1 of the February 21 document
specifies deleting the mention of these.
> The form label:registry is given on p38 where for #\, "In particular,
> an implementation may support names of the form label:registry."
> It could do with repeating on p35 (name-char, char-name).
"_may_ support"? It seems like either this should be part of the standard or
not. What does CHAR-NAME return for non-standard characters if the
implementation doesn't support this? If you are going to permit referencing
names that way, then what do we need registries for? Also, the sentence
quoted is in the context of non-graphic characters. What about names for
non-standard graphic characters? Do standard graphic characters have names?
∂02-Mar-89 1632 X3J13-mailer minor comments on the character proposal
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Mar 89 16:31:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 549744; Thu 2-Mar-89 19:29:32 EST
Date: Thu, 2 Mar 89 19:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: minor comments on the character proposal
To: Thom Linden <baggins@IBM.com>
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <890222.120815.baggins@almvma>
Message-ID: <19890303002938.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
These comments are not an official response to your request for a vote.
Here are some comments on the character proposal version of 21 Feb 89.
I believe these are all merely editorial, but if they are matters of
disagreement I'd like to know.
p.29, describing character attributes: It needs to be clarified that
these notes apply to all implementation-defined character attributes,
not just to attributes that might be provided for compatibility with
the earlier version of Common Lisp.
Some of these notes have not been consistently reflected elsewhere in
the proposal, for example, page 31 seems to say that the only difference
between char-equal and char-= involves alphabetic case, whereas page 29
says that char-= compares all attributes but char-equal compares an
implementation-defined set of attributes (page 29 is correct).
Similarly, where p.31 says "if the codes of two characters differ, then
they are different", it should instead say "if the codes or
implementation-defined attributes (if any) of two characters differ,
then they are different."
Two of the notes on p.29 refer to char-int and int-char, which you are
proposing to remove, so those notes should be removed.
p.33, 35: Under find-char, char-registry-name, and char-label you
indicate that registry names and labels are strings. In fact they
are symbols now, these places need to be updated.
p.38: Where it says "an implementation may support names of the
form label:registry", I believe this to be a typo for "registry:label".
The colon is evidently being used by analogy to packages, so the
registry name should precede the label, just as the package name
precedes the symbol name.
∂02-Mar-89 1909 X3J13-mailer cs proposal and straw vote
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Mar 89 19:09:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 549840; Thu 2-Mar-89 22:06:27 EST
Date: Thu, 2 Mar 89 22:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: cs proposal and straw vote
To: Dan L. Pierson <pierson@mist.encore.com>
cc: baggins@ibm.com, x3j13@SAIL.STANFORD.EDU
In-Reply-To: <8903012050.AA11442@mist.>
Message-ID: <19890303030636.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 01 Mar 89 15:49:59 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
Problem: CHAR-INT behavior is CHAR-CODE unless implementation
defined attributes are supported.
Proposal:
Remove CHAR-INT
IF: Moon agrees that this is sufficient for hashing (or I'm convinced that
he's wrong :-)).
This is actually an interesting issue. I was going to say that CHAR-INT
is not needed, because you can use SXHASH. After all, in any reasonable
implementation SXHASH of a character would just return the CHAR-INT, and
the only difference would be the extra cost of a type dispatch, which
might even be compiled out in some cases. Then I tried the most
reasonable implementation I know and found that SXHASH and CHAR-INT did
not return the same value. So then I did what I should have done at the
beginning, and read the documentation of SXHASH. SXHASH doesn't just
return any useful hash code, it returns one that remains constant for
all time, within "the same" implementation. This means that in any
implementation that dynamically assigns numeric encodings of any
character attribute, SXHASH cannot be the same as CHAR-INT. Genera, for
example, allows user-defined character registries and user-defined
character style attributes, and thus dynamically assigns the numeric
encoding of both character code and character style.
There are many applications of hashing for which the perpetual equality
properties of SXHASH are unwanted, and the associated efficiency cost
is undesired.
So now my opinion is that CHAR-INT should be retained, but INT-CHAR
and its shadow in the COERCE function should be removed.
What do STRING-LESSP, etc. mean for non-standard-character strings?
Isn't STRING-LESSP defined in terms of CHAR-LESSP? CHAR-LESSP has "the
results are unspecified" for two characters in different registries, I
assume, which means that STRING-LESSP of two strings of extended
characters in the same registry is perfectly well defined, and of
characters in different registries returns either true or false, but is
harmless.
∂02-Mar-89 1929 X3J13-mailer answer to request for comments on comments on comments on characters
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Mar 89 19:28:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 549853; Thu 2-Mar-89 22:26:02 EST
Date: Thu, 2 Mar 89 22:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: answer to request for comments on comments on comments on characters
To: Thom Linden <baggins@IBM.com>
cc: Common Lisp mailing <x3j13@SAIL.STANFORD.EDU>
In-Reply-To: <890222.100432.baggins@almvma>
Message-ID: <19890303032620.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
In your comments on my comments on the 1 Jan 89 character proposal,
you asked some questions. Here are my answers. These are personal
answers rather than Symbolics' official position.
Date: Wed, 22 Feb 89 10:04:32 PST
From: Thom Linden <baggins@IBM.com>
>> From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
>> Subject: Comments on the Character proposal dated January 1, 1989
>>
>> The default for :ELEMENT-TYPE has two viable choices that I can see
>> both and let people vote:
>>
>> (1) CHARACTER. This matches the behavior of MAKE-STRING and friends,
>> (2) The most natural type for the particular pathname being opened.
>> The relationship of option 2 to :ELEMENT-TYPE :DEFAULT (a feature that
>> already exists in Common Lisp) needs to be clarified. Perhaps they
>> are the same.
The same? I don't understand. For example, I can imagine the
element-type default as base-character and the external format
defaulted to either an ASCII or EBCDIC encoding.
I think you misunderstood. I was suggesting that perhaps the default
value for the :ELEMENT-TYPE option to OPEN should be the symbol
:DEFAULT. This doesn't relate to the external coding format as far as I
can see, except for whatever niceness we see in having the default
value for both :ELEMENT-TYPE and :EXTERNAL-CODED-CHARACTER-FORMAT be the
symbol :DEFAULT.
I see that in the 21 Feb 89 proposal you have made the default value for
the :ELEMENT-TYPE option to OPEN be implementation dependent, but not
:DEFAULT. In fact they are different, because :DEFAULT can open in
either a character type or an integer type, but (the unnamed) default
can only open in a character type. I can live with what you have
proposed, although I still believe that requiring :ELEMENT-TYPE to
default to CHARACTER might be better, and I'm a little concerned about
having a default for which there is no name within the language. I'd
also like to hear opinions on whether we need two different ways to say
"the most natural type for the particular pathname being opened", with
one of them restricted to subtypes of CHARACTER and the other
unrestricted.
More importantly, though, I think people should be given the choice
of voting between the two options mentioned above (as well as any other
options that garner some support, if there are any). As it stands
the :ELEMENT-TYPE option to OPEN isn't in the straw ballot at all,
there's just a change in the back of the proposal.
>> Also the following promise from 14 November did not show up in the report:
>>
>> >> There should be a name for the "natural" encoding and there should be a
>> >> specification of the properties of the natural encoding that a programmer
>> >> can rely on. Suggestions for the name include :BASE, :NATURAL, and
>> >> :INTERCHANGE. The definition probably involves the concept of data
>> >> interchange with non-Lisp programs on the same system.
>>
>> This will be added to the revision.
I lied. No one came up with the 'properties' of such an encoding.
Do you have some text to suggest?
I'm not sure if your :DEFAULT for :EXTERNAL-CODED-CHARACTER-FORMAT is
intended to be "natural" as well as "default", or not. I'm afraid
I haven't been able to come up with a good description of what it
means to be "natural", though. Perhaps I'm familiar with too many
oddball systems, which makes me more scared of trying to define the
concept than would be someone who only knew Unix. I think we can
safely drop this issue without much harm to the language.
>> No particular page -- We agree with the deprecation or deletion of the two
>> particular character attributes defined by CLtL, but not with the
>> deprecation of the whole concept of character attributes. In fact on page
>> 20 you say "characters are uniquely distinguished by their codes," which
>> makes it impossible to have character attributes at all. The language must
>> define how conforming programs should be written so that they will work
>> both in implementations with character attributes and in implementations
>> without them. For example, the value of (eql x (code-char (char-code x)))
>> is unspecified. Another thing that needs to be said is that the exact
>> character operations (char=, string=, etc.) respect all character
>> attributes, while the inexact character operations (char-equal,
>> string-equal, etc.) respect or ignore each character attribute in an
>> implementation-defined but consistent fashion.
This has improved in the 21 Feb 89 version, but I think more a explicit
statement is still required. You are welcome to borrow the language
("exact", "inexact") that I used just above.
Some of what you say on
>> page 44 about attributes in general needs to be part of the spec, not
>> deprecated. I would retain everything on that page except for INT-CHAR and
>> the last bullet (referring to bits and fonts), and I would add a remark
>> that FIND-SYMBOL and INTERN respect character attributes. If you want,
>> perhaps I or someone else at Symbolics can provide exact text for what
>> to say about character attributes that you could insert into your report.
I moved the attribute list previously in Appendix B back into the
description of characters. Let me know what text you would like
to see for FIND-SYMBOL and INTERN and I'll add it to the list.
After "It is implementation dependent whether attributes are removed
from symbol names by READ" (and by the way, in this and the preceding
bullet I believe "whether" shoudl be changed to "which", since an
implementation with several character attributes might have good reason
to remove some and retain others), I would add "The functions FIND-SYMBOL
and INTERN do not remove character attributes."
∂02-Mar-89 1941 CL-Characters-mailer Really about TYPEP failures: Comments on the Character proposal dated January 1, 1989
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Mar 89 19:41:42 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 549857; 2 Mar 89 22:39:01 EST
Date: Thu, 2 Mar 89 22:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Really about TYPEP failures: Comments on the Character proposal dated January 1, 1989
To: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
cc: Jon L White <jonl@lucid.com>, Baggins@IBM.COM, CL-Characters@SAIL.STANFORD.EDU,
X3J13@SAIL.STANFORD.EDU, Common-Lisp-Implementors@Symbolics.COM, KMP@Symbolics.COM,
Palter@Symbolics.COM
In-Reply-To: <19890204142708.2.RWK@CALVARY.ILA.Dialnet.Symbolics.COM>
Supersedes: <19890303023922.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Removed % signs
Message-ID: <19890303033902.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 4 Feb 89 09:27 EST
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
Legitimate operations on BASE-CHARACTER do not
produce characters in (AND CHARACTER (NOT BASE-CHARACTER)).
I'm not sure which programs written using symbols in the LISP package
are "legitimate operations" and which are not. However, I didn't see
anything in the 21 Feb 89 proposal that says that CHAR-UPCASE of
a BASE-CHARACTER is necessarily a BASE-CHARACTER, for example.
That doesn't sound unreasonable, though; should it be added?
∂03-Mar-89 0004 X3J13-mailer cs comments
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 3 Mar 89 00:03:57 PST
Date: Thu, 02 Mar 89 17:19:25 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890302.171925.baggins@almvma>
Subject: cs comments
>> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>> Subject: minor comments on the character proposal
>>
>> These comments are not an official response to your request for a vote.
>>
>> Here are some comments on the character proposal version of 21 Feb 89.
>> I believe these are all merely editorial, but if they are matters of
>> disagreement I'd like to know.
>>
>> p.29, describing character attributes: It needs to be clarified that
>> these notes apply to all implementation-defined character attributes,
>> not just to attributes that might be provided for compatibility with
>> the earlier version of Common Lisp.
Ok.
>>
>> Some of these notes have not been consistently reflected elsewhere in
>> the proposal, for example, page 31 seems to say that the only difference
>> between char-equal and char-= involves alphabetic case, whereas page 29
>> says that char-= compares all attributes but char-equal compares an
>> implementation-defined set of attributes (page 29 is correct).
>> Similarly, where p.31 says "if the codes of two characters differ, then
>> they are different", it should instead say "if the codes or
>> implementation-defined attributes (if any) of two characters differ,
>> then they are different."
The intent was that p29 defined all the modified behaviors when
implementation-defined attributes were supported. I could repeat these
notes (through modified text) at each of the referenced locations or
make the intent of p29 stronger. Which do you feel is clearer?
>>
>> Two of the notes on p.29 refer to char-int and int-char, which you are
>> proposing to remove, so those notes should be removed.
Correct.
>>
>> p.33, 35: Under find-char, char-registry-name, and char-label you
>> indicate that registry names and labels are strings. In fact they
>> are symbols now, these places need to be updated.
Right.
>>
>> p.38: Where it says "an implementation may support names of the
>> form label:registry", I believe this to be a typo for "registry:label".
>> The colon is evidently being used by analogy to packages, so the
>> registry name should precede the label, just as the package name
>> precedes the symbol name.
>>
Ok.
∂03-Mar-89 0913 X3J13-mailer cs comments
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Mar 89 09:13:20 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 550140; Fri 3-Mar-89 12:10:42 EST
Date: Fri, 3 Mar 89 12:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: cs comments
To: Thom Linden <baggins@IBM.com>
cc: Common Lisp mailing <x3j13@SAIL.STANFORD.EDU>
In-Reply-To: <890302.171925.baggins@almvma>
Message-ID: <19890303171050.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 02 Mar 89 17:19:25 PST
From: Thom Linden <baggins@IBM.com>
>> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>> Subject: minor comments on the character proposal
>>
>> Some of these notes have not been consistently reflected elsewhere in
>> the proposal, for example, page 31 seems to say that the only difference
>> between char-equal and char-= involves alphabetic case, whereas page 29
>> says that char-= compares all attributes but char-equal compares an
>> implementation-defined set of attributes (page 29 is correct).
>> Similarly, where p.31 says "if the codes of two characters differ, then
>> they are different", it should instead say "if the codes or
>> implementation-defined attributes (if any) of two characters differ,
>> then they are different."
The intent was that p29 defined all the modified behaviors when
implementation-defined attributes were supported. I could repeat these
notes (through modified text) at each of the referenced locations or
make the intent of p29 stronger. Which do you feel is clearer?
I feel strongly that in the eventual language standard, it will not be
acceptable to have two sections that speak inconsistently about the same
thing, with the reader told that one section takes precedence over the
other. Thus in the eventual document, this kind of information must be
repeated (at least by reference) at each occurrence. For example, you
can't say in one place "char-equal is the same as char-= except it ignores
alphabetic case" and then say in another place "the other description
of char-equal was simplified for your comfort and convenience, the real
description is char-equal is the same as char-= except it ignores
alphabetic case and some implementation-defined character attributes."
I'm not sure what this says about your document, which is so far from
being in the form of the eventual language standard. It is very
difficult to know whether we are voting on chapters 1 and 2 of the
document, on appendix A of the document, or on the abbreviated "cleanup
issues" in your straw poll. If we're not voting on Appendix A there
is little advantage in spending time making it self-consistent.
Some observers may be wondering why I want implementation-defined
attributes to be discussed in the standard, instead of merely being
defined by the implementations. The issue is to make it possible to
write programs that are both conforming and portable among
implementations with varying implementation-defined attributes, without
the programmer first having to study and compare the documentation of
all the implementations. In other words, the Common Lisp language
standard should define the framework for implementation-defined
character attributes, and the individual implementations should just
fill in that framework. If the language didn't mention the possible
existence of implementation-defined character attributes, it would
be too easy to write a program that at first seemed conforming, but
in fact would not behave as desired on an implementation with
character attributes.
∂03-Mar-89 1006 X3J13-mailer Issue: ERROR-TERMINOLOGY
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Mar 89 10:06:46 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03990g; Fri, 3 Mar 89 10:00:10 PST
Received: by challenger id AA20493g; Fri, 3 Mar 89 09:55:26 PST
Date: Fri, 3 Mar 89 09:55:26 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903031755.AA20493@challenger>
To: x3j13@sail.stanford.edu
Subject: Issue: ERROR-TERMINOLOGY
I looked at the error terminology section as if I were the editor of
the specification, and I made some further changes. I had made an
earlier pass over the material that was intended to tighten it up, but
one can almost always continue to improve things. I showed this draft
to Moon and he said ``I am entirely happy with your proposed rewording
of the error terminology.''
The remainder of this message contains the proposed rewording:
Issue: ERROR-TERMINOLOGY
References: Chapter 5, Section 5.1, Working draft of the standard
CLOS Chapter 1
CLtL Chapter 1, Section 1.2.4
Condition System, Version 18
Category: Clarification
Edit history: 27-DEC-88, Version 1 by Chapman
31-JAN-89, Version 2 by Chapman
6-FEB-89, Version 3 by Chapman, RPG and Barmar comments included
8-FEB-89, Version 4 by Chapman, added more to Current Practice
21-FEB-89, Version 5 by Chapman, added van Roggen, RPG comments
3-MAR-89, Version 6 by Gabriel, rewrite prompted by Moon
Problem Description:
In CLtL, CLOS and the Condition System, similar but slightly
different language is used to describe
non-normal actions by CL operators. The X3J13 committee needs to
agree on a standard set of terms and their meanings.
Proposal (ERROR-TERMINOLOGY:STANDARD TERMS)
TERM MEANING
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
CONFORMING CODE (*) Code that adheres to the following requirements:
(1) Conforming code shall not use any constructions
that are prohibited by the standard.
(2) Conforming code shall not depend on extensions
included in an implementation.
SAFE CODE (*) Code processed with the SAFETY optimization at its
highest setting. SAFETY is a lexical property of code.
UNSAFE CODE (*) Code processed with lower safety levels.
Note: Unsafe code is not necesarily code that does
not do error checking: Implementations are
permitted to treat all code as safe code all the time.
IS SIGNALLED An error is signalled in both safe and unsafe code.
Conforming code may rely on the fact that the error
will be signalled in both safe and unsafe code.
Every implementation is required to detect the error
in both safe and unsafe code. For example, "an error
is signalled if UNEXPORT is given a symbol not
accessible in the current package."
SHOULD BE SIGNALLED An error will be signalled in safe code, and an error
might be signalled in unsafe code.
Every implementation is required to detect the error
at least in safe code. When the error is not
signalled, the "consequences are undefined" (see
below). For example, "an error should be signalled
if ENDP is given a non-list argument."
CONSEQUENCES ARE UNSPECIFIED The consequences are unpredictable but harmless.
Implementations are permitted to specify the
consequences of this situation. No conforming code may
depend on the results or effects of this situation,
and all conforming code is required to treat the
results and effects of this situation as unpredictable
but harmless. For example, ``the consequences of the
garbage collector when invoked are unspecified.''
CONSEQUENCES ARE UNDEFINED The consequences are unpredictable. The
consequences may range from harmless to fatal. No
conforming code can depend on the results or
effects. Conforming code must treat the results and
effects as unpredictable. In places where the
words "must", "must not" or "may not" are used,
then "the consequences are undefined" if the stated
requirement is not met, and no specific consequence
is explicitly stated. For example: "Once a name
has been declared by DEFCONSTANT to be constant,
any further assignment or binding of that special
variable has undefined consequences."
RETURN VALUES ARE UNSPECIFIED Only the number and nature of the return values
of a construct are not well specified but any
side-effect and transfer-of-control behavior is well
specified. For example, if the return values of some
function F are unspecified, then an expression such as
(length (list (F))) is still well-specified because it
does not rely on any particular aspect of the value or
values returned by F.
IMPLEMENTATIONS MAY BE EXTENDED An implementation is free to treat the
situation in ANY ONE of the following ways: (1)
When the situation occurs, an error is signalled at
least in safe code, OR (2) When the situation
occurs, the "consequences are undefined", OR (3)
When the situation occurs, the consequences are
defined. Also, no conforming code can depend on
the results or effects of this situation, and all
conforming code must treat the results and effects
of the situation as undefined. For example,
"implementations may be extended to define other
type specifiers to have a corresponding class."
FREE TO EXTEND THE SYNTAX Implementations are permitted to define unambiguous
extensions to the syntax of the construct being
described. No conforming code can depend on this
extension. All conforming code is required to treat
the syntax as meaningless. The standard may disallow
certain extensions while allowing others. For example,
"no implementation is free to extend the syntax of
DEFCLASS."
WARNING IS ISSUED A warning is issued, as described in WARN, in both
safe and unsafe code and when the situation is
detected by the compiler. Conforming code may rely
on the fact that a warning will be issued in both
safe and unsafe code and when the situation is
detected by the compiler. Every implementation is
required to detect this situation in both safe and
unsafe code and when the situation is detected by
the compiler. The presence of a warning will in no
way alter the value returned by the form which
caused the situation to occur. For example, "a
warning is issued by the compiler if a declaration
specifier is not one of those defined in Chapter 9
of CLtL and has not been declared in a DECLARATION
declaration."
WARNING SHOULD BE ISSUED A warning may be issued. Conforming code may not
rely on the fact that a warning will be issued. If
the situation is detected by the compiler, a
warning may or may not be issued, depending on the
implementation. The presence of a warning will in
no way alter the value returned by the form which
caused the situation to occur. For example, "a
warning should be issued by a compiler if a
variable declared to be ignored is referenced
or is also declared special, or if a variable is
lexical, never referenced, and not declared to be
ignored."
(*) means this term is used to define other terms in this proposal,
not explicitly used in the standard.
∂03-Mar-89 1130 X3J13-mailer Re: Section 1.7
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 3 Mar 89 11:30:17 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA13011; Fri, 3 Mar 89 11:28:34 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA12864; Fri, 3 Mar 89 11:24:49 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA26139; Fri, 3 Mar 89 11:27:58 PST
Date: Fri, 3 Mar 89 11:27:58 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903031927.AA26139@clam.sun.com>
To: barmar@Think.COM, pierson@mist.encore.com
Subject: Re: Section 1.7
Cc: chapman%aitg.DEC@decwrl.dec.com@Multimax.encore.com,
skona%csilvax@hub.ucsb.edu@multimax.encore.com,
x3j13@sail.stanford.edu
I agree with Barry. Packages not named in the standard belong
to software developers. Otherwise every name defined by anyone
becomes an extension to Common Lisp, and I don't think we want
to define "extension" that way.
∂03-Mar-89 1202 X3J13-mailer Common Lisp
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 Mar 89 12:02:33 PST
Received: from fafnir.think.com by Think.COM; Fri, 3 Mar 89 14:56:49 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 3 Mar 89 14:58:31 EST
Received: by verdi.think.com; Fri, 3 Mar 89 14:55:18 EST
Date: Fri, 3 Mar 89 14:55:18 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903031955.AA21691@verdi.think.com>
To: moore@cli.com
Cc: x3j13@sail.stanford.edu
Cc: Steele@Think.COM
In-Reply-To: J Strother Moore's message of Fri, 3 Mar 89 10:44:34 CST <8903031644.AA08035@client13.CLI.COM>
Subject: Common Lisp
Date: Fri, 3 Mar 89 10:44:34 CST
From: J Strother Moore <moore@cli.com>
I just wanted to let you know that I love Common Lisp.
I have used it a lot this past year extending Boyer's and
my theorem prover and the more I've used it the more I
like it. You guys really did a great job.
J
Thank you very much for the compliment. ANSI committee X3J13
is working to clean up the rough spots and fill in the gaps;
I hope you like the revision as much as the current definition.
And of course lots of credit must go to the implementors.
This mail made my day.
--Guy Steele
∂03-Mar-89 1221 X3J13-mailer KMP's personal comments on 22-Feb-89 Character Proposal
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Mar 89 12:21:23 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 550353; Fri 3-Mar-89 15:17:40 EST
Date: Fri, 3 Mar 89 15:17 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: KMP's personal comments on 22-Feb-89 Character Proposal
To: Baggins@IBM.COM
cc: X3J13@SAIL.Stanford.EDU
References: <19890303165649.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890303201737.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Please find below my personal comments on the hardcopy character
proposals of 22-Feb-89 which I received from you by US Mail.
This is not the Symbolics official position. Moon will send that
at a later date.
Note that this will be my only mailing to this large list on this
issue prior to the meeting. If I have anything further to say, I
will bring it up on CL-Characters or some smaller list. I expect,
however, that my attention will be focused on other issues.
By the way, you still have my old address (11 Cambridge Center).
The correct new address for me, Moon, and Symbolics R&D is:
8 New England Executive Park, East
Cambridge, MA 01803-5007
----- Comments on the Isolated Proposals (hardcopy of 22-Feb-89) -----
Presentational Comments
- This doesn't follow the normal proposal format being used by
other groups. As a consequence...
- there are no examples to make certain sticky points clearer
- there is no impact analysis
- there is no rationale for some of the questionable changes
I think it is unreasonable to expect people to just infer this
kind of thing. Reasoning about these things takes a lot of time.
Writing down your thoughts once you've reasoned about something
takes much less time than asking someone to repeat your entire
process in order to decide if they approve.
Also, there is precedent for making decisions in language design
that later are suggested to be mistakes. Often it is hard to
distinguish `changing goals' from `poor communication' from
`oversight' from `typo.' Our normal proposal format is designed
to avoid some of these symptoms by making explicit some things
that would not be explicit in the final document, and by adding
redundancy that helps catch typos, miscommunication, etc.
- The proposal descriptions are far too brief. They are prone to
misinterpretation. Worse, an `expansion' does not occur elsewhere.
Often to disambiguate you have to do a lot of digging around and
assembling things from pieces here and there.
At the very least, there should be index information from these
short punchy phrases to something less ambiguous. Better still
would be to really spell out the details in the proposal so that
they can be examined in the abstract.
Breaking this big proposal up into little ones should have
accomplished two things: it should have allowed us to understand
the parts of the proposal in isolation, and it should have allowed
independent voting. I think it currently allows neither, because
you can't understand the individual proposals without understanding
the whole and if you vote No on any particular part, you aren't left
with a document that Kathy can usefully work with.
Technical Comments
- Regarding defining that STRING-CHAR must be either BASE-CHAR or
CHARACTER -- This seems unmotivated and I am suspicious of it.
It seems, somehow, unnecessarily restrictive.
- I don't mind if INT-CHAR is removed, but I don't think CHAR-INT
should be removed. It may be useful in some hashing applications.
- Regarding the problem description in CHARACTER-TYPE-RESTRICTIVE,
I don't think that I believe that CHARACTER doesn't allow both fat
and thin characters. Is this claim motivated somewhere.
- The proposal CHARACTER-TYPE-RESTRICTIVE suggests replacing
STANDARD-CHAR by (CHARACTER :STANDARD), but since STANDARD-CHAR
is not really going away, this wording is misleading.
- Proposals STRING-TYPE-RESTRICTIVE and SIMPLE-STRING-TYPE-RESTRICTIVE
refer to making STRING and SIMPLE-STRING (respectively) union types.
The details of this are never spelled out. The consequences are not,
I think, appropriately analyzed. I would like to better understand the
relationship between this and the new array TYPEP situation to make
sure there are no bad interactions.
- I do not understand from the description of
SIMPLE-STRING-TYPE-ABBREVIATIONS why adding SIMPLE-BASE-STRING
and SIMPLE-GENERAL-STRING is an answer to the problem that new types
are awkward to name.
Aesthetic Comments
- I think the terms `coded character format' and `coded character set'
are ok for a concept description, but inappropriate for a language spec.
They are too long for convenient lunch table discussion, note taking,
etc. If you want something to be part of a language that people use in
a serious way, you have to either truncate the terms to manageable
size or expect people to do it for you. If you do it, at least that
visitors from other companies will be able to participate in lunch
table discussions. If you let your users do it, there will be lots of
gratuitous variation. The impact of this is that...
- In FILE-EXTERNAL-REPRESENTATION, :EXTERNAL-CODED-CHARACTER-FORMAT
is far too long. In any situation, such as with OPEN, where the
space of keywords is not user-extensible, the need for
extraordinarily long names is very low because short names can
adequately disambiguate. I see no reason why some much shorter
keyword cannot be devised. (Just for your reference, even
:IF-DOES-NOT-EXIST tries my patience.)
I suggest :EXTERNAL-ENCODING as a straw man, but all I really care
about is that it be a minimal number of words, and I don't think
the proposed choice is short enough.
- In STRING-BINARY-WIDTH, I think the name EXTERNAL-CODED-STRING-LENGTH
is again too long. It's not like people will ever add symbols to
the LISP package, so it's not like a shorter name would be ambiguous.
I suggest STRING-ENCODED-LENGTH (to match my :EXTERNAL-ENCODING above).
- In CHAR-CODE-NON-PORTABLE, I very strongly dislike abbreviations except
in extraordinary circumstances like `char' where the abbreviation is
nearly ripe for adoption as an English word due to its extremely wide,
or where the word is used so often that spelling it out would be too
awful.
However, if you spell it out, I'll complain that it is too long a term.
I propose you call the thing CHAR-ENCODING.
- In CHARACTER-IDENTIFICATION-NONPORTABLE, I don't think you've necessarily
solved anything if you say that (a) all characters must come from some
registry and (b) all registries must be dicated by an ISO group that doesn't
exist. It necessarily follows that there can be no correct implementation
until that working group finishes. What are people to do in the interim?
It either needs to be spelled out, or it needs to be explained why what they
do doesn't matter. [And, indeed, if it doesn't matter, then it's going to be
hard to make the case that a lot of the existing rules are really necessary.]
Typos
- In CHARACTER-TYPE-RESTRICTIVE, defining BASE-CHARACTER as a subtype
of STRING seems like an extraordinarily bad idea. :-)
- In STRING-BINARY-WIDTH, presumably the function name does not want
to be in the KEYWORD package.
----- Comments on the Concept Part (hardcopy of 22-Feb-89) -----
Presentational Comments
- The proposal uses the term "removed" a lot but that sometimes seems to
mean "gets totally rid of", sometimes means "deprecates", sometimes
means "adds something that's really better". Maybe I'm just misreading,
but it would be helpful in terms of being a proposal that people have to
vote on, to clearly define these terms.
- I am actually offended by the use of these tags like ISO8859/2-1987
with no exposition. This gives a `snobby' look to the paper and amounts
to jargon because it is not intelligible by people who are on in on
ISO affairs. I feel forced to write to ISO to get these documents just
to know what you're talking about. I have no sense for whether you are
talking about something I'm familiar with under another name, or
something totally irrelevant to me. I made annotations all over the
document about this. It was really starting to bug me.
- p9, last two paragraphs before 2.3 should be a single paragraph.
- I found it hard to read about REGION-SPECIALIZED-STRING, GENERAL-STRING,
etc. and then to think that you weren't in fact proposing it. Someone
skimming would probably miss the word `hypothetical' ... Especially since
my vague recollection is that this stuff was really in a previous proposal,
I think this stuff either be much more clearly set off as an example.
Technical Comments
- From a human interface standpoint, I think it would be desirable for
character repertoires to have more than one possible name. My guess
is -- though I have no way of proving it since no hint is given about
what names these things refer to -- that these things have more common
nicknames that would be more programmer-friendly if allowed. Names made
up of mostly digits are not appealing to me.
- If people can add non-stanard registries, there is a potential for
confusion. If I add a private registry named FOO and then at a later
time ISO votes in a registry named FOO, mine will suddenly appear to
be the official one. If there a way to tell official ones from unofficial
ones, that might avoid some problems down the road. Alternatively, if
a portion of the registry namespace were allocated for ISO (or,
conversely, reserved for private use), that would solve the problem.
- The fact that character labels must be uniquely named using only
standard-char-p characters strikes me as having funny bootstrap
implications. I don't know what if anything to do about that, but I
thought I'd mention it.
- The issue of character labels also makes me wonder about uses of
special chars like colon, backslash, semicolon, dollarsign which often
have special meaning to Lisp and other languages. Further, the use
potential to use underscore and hyphen seems like a bad idea, too,
because some systems prefer underscore to hyphen -- and vice versa.
Personally, I think we ought to say that character labels have to be
made of A to Z, a to z, and 0 to 9 (with preference for alphabetics
over numerics -- i.e., they should try to be actual words).
- Also, who will assign character labels? Will they not be standard
across implementations? This is a place where examples of sample uses
would help a lot.
- I couldn't make sense of the cryptic phrase `Reader Canonicalization'
in a bullet item at bottom of chap 2, page 8. I think this should
be elaborated.
- I've wrestled with this business of (and character (not base-character))
a lot and come to the conclusion that you should give this a name
in the language itself. e.g., you should deftype the name
extended-character. The reasons are these:
- so it can be used in discussions, bug reports, etc.
- so that there is a term that could be common between lisp and some
other language -- where the other language was non-lispy and a lisp
AND expression would not be welcome.
- When the external encoding is not reliably using a single-byte format,
you need to specify the consequences for the functions FILE-POSITION
and FILE-LENGTH.
- Is $ really what is replaced by the British pound sign on British
displays? I had always thought that # was what was replaced. My point,
though, is that there may be more than one axis on which to view
`equivalent functionality.'
I don't think I'm disagreeing with you on the details here, but I am
saying that I don't think it's as pretty a picture as you paint it,
and that (like the `pathnames' section in CLtL) you risk making people
think they're getting a more comfortable solution than they're really
getting.
I think the real point here should be that this is a thing which
gratuitously varies in the marketplace and in the world, that we don't
have a prayer of standardizing it, and we're leaving it up to vendors
to do the best they can.
I have a couple of specific questions, though:
- What if a program that on American terminals types out:
That will cost $4.00
types out
That will cost L4.00
on a british screen. I'm not so sure I'm happy with that.
- What about _ vs -. Some computer systems seem to take languages
that are defined to distinguish case (and be all uppercase) and
invert the case (make it all lowercase), often flipping hyphen
and underscore, and single and doublequote in the process. Are
these valid transformations?
- top of p13, you say that the COERCE function is extended to allow
for coercion from base string to extended string. Be explicit about
how this is done.
- Regarding footnote 18 on p13, my personal feeling is that either all
conventions should be itemized or none should. If none are, you can
pick obviously hypothetical names. However, I think that to mention
one or two encodings and not others amounts at best to advertising
and at worst can either pin an implementation unnecessarily (by having
an external document such as CLtL or the ANSI CL spec define something
which might want to vary over time) or can cause a market bias toward
implementations which have their convention mentioned over implementations
which do not have their conventions mentioned.
- The whole issue of non-graphic characters is almost totally omitted
from the discussion. I think more should have been said. A parenthetical
remark about #\Newline at top of p14 of chap 2 is about all there seemed
to be.
- I think the reason that EXTERNAL-CODED-STRING-LENGTH does not address
the problem of screen width in proportional fonts should be addressed.
Is an implication also that Huffman coding (is that how you spell it)
in stream output is also not addressed (or possibly illegal) because
it is context sensitive?
Typos
- You've put some function names in italic where you meant code-font.
e.g., in Section 2.1
-----
Due to time constraints, I only skimmed the editorial modifications to
CLtL in trying to get answers to specific questions I ran into in the
other parts. The absence of remarks about those changes shouldn't
necessarily be construed at this time as approval on my part.
∂03-Mar-89 1427 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 3 Mar 89 14:27:24 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA19379; Fri, 3 Mar 89 14:27:47 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA21544; Fri, 3 Mar 89 14:23:46 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA26314; Fri, 3 Mar 89 14:27:06 PST
Date: Fri, 3 Mar 89 14:27:06 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903032227.AA26314@clam.sun.com>
To: rpg@lucid.com, x3j13@sail.stanford.edu
Subject: Re: Issue: ERROR-TERMINOLOGY
The terminology "CONSEQUENCES ARE UNSPECIFIED" is still a
trap in my opinion. The example, ``the consequences of the
garbage collector when invoked are unspecified'', is not
as appropriate as it might be, because there is no explicit
way to invoke the garbage collector in Common Lisp and the
example is not taken from the specification of the language
as far as I know.
But, what the heck, let's look at this example. Are the
results and effects of this situation "unpredictable but
harmless"? Not in my book. Running the garbage collector
is supposed to have (essentially) *no* visible effects.
It can't change the value of any variable or data structure
in any observable way. It can issue messages, I guess, and
change the report from "ROOM", but that is likely to change
with every call anyway.
Let's pick a few actual examples where the language definition is
proposed to say "consequences are unspecified". (Go ahead, I challenge
you.) I think we will find that the description will have to be more
specific than that. It can make sense to say that "effect X may or may
not occur". It can make sense to say that "data structure Y may be
modified arbitrarily". If we can define a set of effects that we
consider harmless, and change "unpredictable but harmless" to just
"harmless", or some such, that could also make sense, but not the current
language.
∂03-Mar-89 1539 X3J13-mailer What is a FUNCTION?
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Mar 89 15:39:21 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA07284; Fri, 3 Mar 89 16:37:18 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA04478; Fri, 3 Mar 89 16:37:16 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903032337.AA04478@defun.utah.edu>
Date: Fri, 3 Mar 89 16:37:14 MST
Subject: What is a FUNCTION?
To: x3j13@sail.stanford.edu
From section 2.2 of the working draft:
A FUNCTION may be supplied as an argument without error to FUNCALL or
APPLY, and is to be executed as code when arguments are supplied. The
functional computation produces one or more values, produces no
values, or takes a non-local exit.
Is this *really* the best definition of what a FUNCTION is that we can
come up with? I've talked to some other people here and while we are
all having a remarkably hard time coming up with some specific words,
we are all agreed that this definition really misses the boat.
Surprisingly, none of the Lisp texts I have handy have much discussion
on what a function is, and the R**3 Scheme report says almost nothing
about what a procedure object is either. I really had no idea that
there was such a gaping hole in our understanding of such an
apparently fundamental concept....
To me, it seems like the definition of the FUNCTION type ought to
incorporate at least the following four notions:
- encapsulation of process as object
- capture of lexical environment
- generalization via parameters
- evaluation of body delayed until funcall
Also I would expect to see a statement that FUNCTION objects are
created by the evaluation of a (FUNCTION (LAMBDA ...)) form.
Would anybody like to take a stab at putting together a better
definition?
-Sandra
-------
∂03-Mar-89 1548 X3J13-mailer Error Terminology
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Mar 89 15:48:06 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00688g; Fri, 3 Mar 89 15:41:25 PST
Received: by challenger id AA21289g; Fri, 3 Mar 89 15:36:54 PST
Date: Fri, 3 Mar 89 15:36:54 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903032336.AA21289@challenger>
To: x3j13@sail.stanford.edu
Subject: Error Terminology
Ok Cris, here is the example. It is from CLOS chapter 1.
The description is of the system-supplied method for
SHARED-INITIALIZE. The second argument specifies a list of
slots that will be dealt with in certain cases.
``There is a system-supplied primary method for {\bf
shared-initialize} whose first parameter specializer is the class {\bf
standard-object}. This method behaves as follows on each slot,
whether shared or local:
...
\item{\bull} Any slots indicated by the second argument that are still
unbound at this point are initialized according to their {\bf
:initform} forms. For any such slot that has an {\bf :initform} form,
that form is evaluated in the lexical environment of its defining {\bf
defclass} form and the result is stored into the slot. For example,
if a {\bf :before} method stores a value in the slot, the {\bf
:initform} form will not be used to supply a value for the slot. If
the second argument specifies a name that does not correspond to any
slots accessible in the instance, the results are unspecified.''
Now, should this say that if the second argument specifies a name that
does not correspond to an accessible slot that it is ignored? Well,
that is what it does in some sense, but there may be processing that
goes on to discover the fact that it should be ignored, so supplying
exactly exactly one slot that appears nowhere in the hierarchy might
take an arbitrary amount of time to discover. For example, if there
are 100,000 classes, the CPL might need to be calculated, which could
take up to 40 seconds and involve CONSing 5mbytes, possibly
side-effecting each class object in certain ways. Or while the
programmer is getting coffee, the multitasking system might have
noticed inactivity and woken up the CPL calculation process, computing
the CPL for the right classes, so when the programmer returns and
causes shared-initialize to happen, this effect doesn't happen. Or
the search for the slot might invoke other internal initialization
procedures or protocols that should be harmless. Or maybe some
programming environment structures are altered. Or maybe some other
processes are started.
Right now I don't know even what the odd effects of the CPL
computation will be in any particular Common Lisp, and the CPL
computation might be involved in the effects of shared-initialize.
I wasn't sure what Cris meant by this argument regarding the garbage
collector:
``But, what the heck, let's look at this example. Are the
results and effects of this situation "unpredictable but
harmless"? Not in my book. Running the garbage collector
is supposed to have (essentially) *no* visible effects.
It can't change the value of any variable or data structure
in any observable way. It can issue messages, I guess, and
change the report from "ROOM", but that is likely to change
with every call anyway.''
I might point out that rehashing can happen as a result of GC, and in
parallel processing extensions to Common Lisp, running processes (such
as those behind futures) could be killed. Output in output buffers
might be shipped to their final destinations. Weak pointer arrays
could be altered. Dispatch tables for generic functions could be
recalculated, and instances whose structure had been redefined by
forward-referencing could be re-optimized, and possibly some metaobject
protocol could be triggered.
But, ignoring these, it sounds offhand like he wasn't sure what
effects GC might have or whether they would happen (``essentially'';
``I guess''), but he was certain there would be no visible effects.
Maybe he thought the results were unpredictable but harmless?
Cris suggests:
``If we can define a set of effects that we consider harmless, and
change "unpredictable but harmless" to just "harmless"....''
My point is that it is very hard to enumerate or classify all possible
effects in all possible implementations with all possible legal
extensions on all possible hardware at all future times. And it is
much easier to define terminology that captures our intent and use it.
-rpg-
∂03-Mar-89 1632 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Mar 89 16:32:40 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09474; Fri, 3 Mar 89 17:30:36 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA04518; Fri, 3 Mar 89 17:30:34 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903040030.AA04518@defun.utah.edu>
Date: Fri, 3 Mar 89 17:30:32 MST
Subject: Re: Issue: ERROR-TERMINOLOGY
To: rpg@lucid.com
Cc: x3j13@sail.stanford.edu
I've been bothered by "the consequences are unspecified" too, although
I've kept my mouth shut on the issue up until now in the hopes that
the problem would resolve itself.
First some background. We've had problems deciding on error
terminology for some of the compiler issues because it seems like none
of the standard error terms really say what we want, which is
something to the effect of: You can't depend on being able to compile
code that does this. In any particular implementation, the behavior
will be well-defined, but that behavior may be (for the compiler
and/or loader) to signal an error. Conforming programs cannot rely on
any particular behavior in this situation, but simply compiling code
that does this will not cause a crash-and-burn situation.
Saying "the consequences are undefined" doesn't seem like the right
thing, because it permits the possibility of random crash-and-burn
errors. I am not sure if "the consequences are unspecified" is really
right either, because I'm not sure if "harmless" was intended to
include signalling an error.
So far, in situations where it is reasonable to signal an error (for
example, issue COMPILE-FILE-SYMBOL-HANDLING), I have been using
"unspecified" but explicitly saying that it is OK to signal an error.
I would feel more confortable with this if the definition of the term
"unspecified" said that signalling errors or warnings is permissible,
at least in those situations where the standard explicitly says it is.
A further problem with "the consequences are unspecified" is that I
think the word "consequences" is too unspecific about is being left
unspecified. :-) We ought to be very careful about using this phrase
and instead try to state exactly which "consequences" are unspecified.
-Sandra
-------
∂03-Mar-89 1704 X3J13-mailer Issue: ERROR-TERMINOLOGY
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Mar 89 17:03:58 PST
Received: from pitney-bowes ([192.9.200.50]) by heavens-gate.lucid.com id AA00803g; Fri, 3 Mar 89 16:57:17 PST
Received: by pitney-bowes id AA11422g; Fri, 3 Mar 89 16:55:51 PST
Date: Fri, 3 Mar 89 16:55:51 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8903040055.AA11422@pitney-bowes>
To: sandra%defun@cs.utah.edu
Cc: rpg@lucid.com, x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Fri, 3 Mar 89 17:30:32 MST <8903040030.AA04518@defun.utah.edu>
Subject: Issue: ERROR-TERMINOLOGY
Why can't we use phrases like:
"the consequences might be fatal"
"the consequences might signal an error"
"the consequences won't signal an error"
For me, saying "the consequences are undefined" is a bit like saying
"slow, construction ahead" when in fact the bridge might be out.
jlm
∂04-Mar-89 1159 X3J13-mailer Error Terminology
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The error terminology is useful for explaining general behavior
in various situations where we do not wish to state explicitly what could
happen, but ordinary English description is not forbidden.
That is, if you want to say that something is unspecified but might
signal an error, we don't need special terminology for that since that
phrase itself is perfectly fine. (Note: ``unspecified'' allows implementations
to specify what happens, and signalling an error is a fine specification.)
In addition, if people feel that we should elaborate on the possible
consequences of some action, we should simply spell them out. The fact we
have error terminology doesn't mean that we cannot use our judgement in
particular situations.
-rpg-
∂06-Mar-89 1133 X3J13-mailer Re: KMP's personal comments on 22-Feb-89 Character Proposal
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 6 Mar 89 11:32:45 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa02296; 6 Mar 89 18:55 GMT
Date: Mon, 6 Mar 89 19:22:51 GMT
Message-Id: <19790.8903061922@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: KMP's personal comments on 22-Feb-89 Character Proposal
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, Baggins@ibm.com
In-Reply-To: Kent M Pitman's message of Fri, 3 Mar 89 15:17 EST
Cc: X3J13@sail.stanford.edu
> - Is $ really what is replaced by the British pound sign on British
> displays? I had always thought that # was what was replaced.
It is often the case that hash is replaced by the british pound sign.
For example, I soon learned to recognize L'(lambda ...). Indeed,
ASCII-based systems (machines, terminals, etc) seem to do this,
though some other things (ICL 1900 series machines, say) may replace
dollar sign with pound.
-- Jeff
∂06-Mar-89 1322 X3J13-mailer Re: minor comments on letter ballot material
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 13:22:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551534; Mon 6-Mar-89 16:19:23 EST
Date: Mon, 6 Mar 89 16:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: minor comments on letter ballot material
To: Gregor.pa@Xerox.COM, chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@SAIL.STANFORD.EDU, skona%csilvax@hub.ucsb.edu
In-Reply-To: <19890302024559.5.GREGOR@SPIFF.parc.xerox.com>
Message-ID: <19890306211857.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Wed, 1 Mar 89 18:45 PST
From: Gregor.pa@Xerox.COM
Date: Wed, 1 Mar 89 18:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Here's a suggestion from one of our CLOS implementors. Would this
change (adding the word "affected") require a vote?
Page 2-9 Redefining Classes
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time a slot of that instance is read or written.
I think I'd prefer if this said:
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time an affected slot of that instance is
read or written.
I (Moon again) think this is a good idea.
This change makes it impossible for people to use MAKE-INSTANCES-OBSOLETE
to arrange for any future access to the slots of an instance to trap.
One of the reasons we gave for not adding an instance enumeration
mechanism was the availability of this functionality. So, I don't think
we should make this change.
We could say that MAKE-INSTANCES-OBSOLETE "affects" all the slots, rather
than saying that it "affects" none of the slots. However, I'm willing to
just drop the issue.
∂06-Mar-89 1348 X3J13-mailer Feb. 21 Letter Ballot: editorial issues
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 13:48:15 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551584; Mon 6-Mar-89 16:45:08 EST
Date: Mon, 6 Mar 89 16:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Feb. 21 Letter Ballot: editorial issues
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902211607.AA09708@decwrl.dec.com>
Message-ID: <19890306214441.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is the official response of Symbolics to the Feb 21 1989
letter ballot on Common Lisp editorial issues.
________________________________________________________________________
Issue or section name | Version | Y | I | A |
------------------------------------------------------------------------
CUT-OFF-DATES | 4 | Y | | |
------------------------------------------------------------------------
ERROR-TERMINOLOGY | 5 | | I | |
------------------------------------------------------------------------
FONTS | 2 | Y | | |
------------------------------------------------------------------------
TOC | 1 | Y | | |
------------------------------------------------------------------------
Section 1.8 | 5.8 | | I | |
------------------------------------------------------------------------
Section 2.3 | 5.8 | | I | |
------------------------------------------------------------------------
Section 2.4 | 5.8 | | I | |
------------------------------------------------------------------------
Section 2.5 | 5.8 | | I | |
------------------------------------------------------------------------
Section 6.1 | 5.8 | | I | |
------------------------------------------------------------------------
Accompanying comments:
ERROR-TERMINOLOGY: The version included with the ballot is inadequate
(details criticisms in comments mailed earlier from Moon and from Pitman).
The more recent draft mailed out by Gabriel is better. We intend to
vote yes when we see a draft that is precise, self-consistent, and
doesn't contain examples that contradict the rest of the definition of
Common Lisp; we believe the most recently mailed draft is quite close to
that and would be surprised not to see an acceptable draft at the March
meeting.
The five numbered sections: We approve these in principle, but aren't
ready to cast them in concrete. We haven't had time to review them with
the extreme care warranted for a language standard, and don't know who
else, if anyone, has reviewed them that thoroughly. We intend to vote
yes when we know that these have been reviewed with good judgement and
attention to detail, or if informed that voting yes does not mean that
these sections will be put into the standard without permitting an
opportunity for further review and correction.
∂06-Mar-89 1355 X3J13-mailer minor comments on letter ballot material
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Mar 89 13:55:10 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02303g; Mon, 6 Mar 89 13:46:42 PST
Received: by challenger id AA25811g; Mon, 6 Mar 89 13:41:55 PST
Date: Mon, 6 Mar 89 13:41:55 PST
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8903062141.AA25811@challenger>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: Gregor.pa@Xerox.COM, chapman%aitg.DEC@decwrl.dec.com,
x3j13@SAIL.STANFORD.EDU, skona%csilvax@hub.ucsb.edu
In-Reply-To: David A. Moon's message of Mon, 6 Mar 89 16:18 EST <19890306211857.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: minor comments on letter ballot material
Date: Mon, 6 Mar 89 16:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Line-Fold: No
This change makes it impossible for people to use MAKE-INSTANCES-OBSOLETE
to arrange for any future access to the slots of an instance to trap.
One of the reasons we gave for not adding an instance enumeration
mechanism was the availability of this functionality. So, I don't think
we should make this change.
We could say that MAKE-INSTANCES-OBSOLETE "affects" all the slots, rather
than saying that it "affects" none of the slots. However, I'm willing to
just drop the issue.
I think it's hard to do. It is specified that class redefintion will call
make-instances-obsolete. So all the slots would be affected whenever a class
redefinition makes the instances obsolete.
We could do it by changing make-instances-obsolete to take a list of slots to
mark as affected.
Patrick.
∂06-Mar-89 1453 X3J13-mailer Re: cs proposal comments
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 14:53:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551649; Mon 6-Mar-89 17:51:21 EST
Date: Mon, 6 Mar 89 17:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: cs proposal comments
To: David N Gray <Gray@DSG.csc.ti.com>, Thom Linden <baggins@IBM.com>
cc: x3j13@sail.stanford.edu
In-Reply-To: <2813859524-5211323@Kelvin>
Message-ID: <19890306225107.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 2 Mar 89 13:38:44 CST
From: David N Gray <Gray@DSG.csc.ti.com>
> >> Never mind that; the real question is why do you want the standard to not
> >> specify the meaning of tabs and form-feeds in source files?
> >>
> I don't have my CLtL with me but I don't think a meaning is given
> to the semi-standard characters (unless we consider them self defining?)
I'm talking about page 336 of CLtL which specifies that the reader treats
#\TAB and #\PAGE as whitespace. Section A.22.1.1 of the February 21 document
specifies deleting the mention of these.
I think I saw several messages complaining about this. I think it would
actually be okay to remove the semi-standard characters, and that this would
not mean that portable programs could not be written with tabs and form-feeds.
It's already the case that when porting a program between implementations one
may have to do character set translation on the source text of the program.
When porting to an implementation that does not have tab or formfeed (which
is already legal), the character set translation must change those into
spaces, or something.
On the other hand, a nice thing about CLtL is the way it said that an
implementation doesn't have to support tabs, but if it does have tabs,
this is how they should work. Thus the programmer can rely on having
only two tab stories to deal with: either tabs work as some amount of
whitespace, or there aren't any tabs at all. Thus it might make sense
to retain these characters with the same semi-standard status. I don't
see how doing that would harm the rest of the characters proposal.
Since it says somewhere that implementations are allowed to support only
a subset of a registry, it would be valid to support only a subset of
the control-characters registry (format-effectors might be a better
name).
∂06-Mar-89 1449 X3J13-mailer Re: cs proposal and straw vote
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 14:49:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551645; Mon 6-Mar-89 17:44:45 EST
Date: Mon, 6 Mar 89 17:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: cs proposal and straw vote
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, baggins@ibm.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903021757.AA03241@defun.utah.edu>
Message-ID: <19890306224429.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 2 Mar 89 10:57:40 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
....
Why do we need CHAR-CODE-LIMIT, CODE-CHAR, and CHAR-CODE anyway?
While bits and fonts were in the standard, these were useful for
things like creating a character with the same code but different bits
or font attributes, but now that's out. If we want a function to use
for hashing characters, that's what CHAR-INT is for. The only other
use I can think of is supporting iteration over characters, and it
seems like this could be extremely inefficient in implementations that
support user-defined character sets. (In such a case, I would imagine
that one would make CHAR-CODE-LIMIT correspond to the limit imposed by
the representation, perhaps the same as MOST-POSITIVE-FIXNUM, but in
actual practice, very few of those codes would have corresponding
characters.) I agree with Dan that we'd be better off having a
specialized iterator.
You left out the most obvious use, which is associating data of some
sort with characters by making an array indexed by char-code. I agree
that this will not be practical in implementations where CHAR-CODE-LIMIT
is very large.
I didn't really understand Dan's suggestion for a specialized iterator,
since in one paragraph he said it was premature to put in character
registries, then in the next paragraph he said there should be an
iterator that takes a character registry and executes the body for
each character in that registry.
I think that the char-code stuff needs to be retained to ease the writing
of applications that are portable between implementations with different
sets of implementation-defined character attributes. However, I would
probably not object strenuously to the removal of the char-code stuff
(I can't promise; I'd have to check with other Symbolians first) since
it could become an implementation-dependent extension.
Should we consider extending MAKE-STRING-OUTPUT-STREAM to take an
:ELEMENT-TYPE keyword?
That seems like a good idea. WITH-OUTPUT-TO-STRING also. An idea which
I slightly prefer is that WITH-OUTPUT-TO-STRING when no string argument
is provided and MAKE-STRING-OUTPUT-STREAM produce a stream that accepts
all characters and returns a string of some element-type that
accomodates all the characters that were actually output. This reflects
Symbolics current practice.
In fact Symbolics Genera will also widen a base-string provided as a
string argument to WITH-OUTPUT-TO-STRING into a general-string if
necessary. If we wanted to put that into the standard, that would be
great as the user would never have to worry about the element-type,
however if other implementors object I won't push it.
∂06-Mar-89 1538 X3J13-mailer Re: cs proposal and straw vote
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 6 Mar 89 15:37:53 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA12950; Mon, 6 Mar 89 18:35:51 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA15870; Mon, 6 Mar 89 18:33:59 EST
Message-Id: <8903062333.AA15870@mist.>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: x3j13@sail.stanford.edu
Subject: Re: cs proposal and straw vote
In-Reply-To: Your message of Mon, 06 Mar 89 17:44:00 -0500.
<19890306224429.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 06 Mar 89 18:33:55 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Mon, 6 Mar 89 17:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I didn't really understand Dan's suggestion for a specialized iterator,
since in one paragraph he said it was premature to put in character
registries, then in the next paragraph he said there should be an
iterator that takes a character registry and executes the body for
each character in that registry.
It's actually very simple. I have doubts about putting registries in
at all, but IF we do decide to put them in there should be a way to
iterate over them.
∂06-Mar-89 1627 X3J13-mailer cs proposal straw vote
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 16:27:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551767; Mon 6-Mar-89 19:23:38 EST
Date: Mon, 6 Mar 89 19:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: cs proposal straw vote
To: Thom Linden <baggins@IBM.com>
cc: Common Lisp mailing <x3j13@sail.stanford.edu>
In-Reply-To: <890222.120815.baggins@almvma>
Message-ID: <19890307002320.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is the official response from Symbolics to the 22 Feb 89
straw vote on the characters proposal.
The format in which this was presented makes it very difficult to
know what we're voting on. Fortunately, it's only a straw poll.
However, you need to be aware that we had to guess what exactly
we're voting on, and so the results of the straw poll might not
be too meaningful, if different participants made different guesses.
I would strongly suggest casting this material into a precise
and unambiguous form before the binding vote occurs. That could
save a great deal of discussion time and minimize the possibility
of perfectly good language features being voted down simply because
of the way they were presented. It's especially important not to
retain the current format, where things are discussed in three places
(the body of the proposal, the appendix, and the ballot) and the
three places contradict each other in significant ways.
Issue: CHAR-FONT-UNUSED-CHAR-BITS-NONPORTABLE
Yes. We will want to check the p.29 rules for implementation-dependent
character attributes carefully.
Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
No. CHAR-INT is needed for hashing. CHAR-INT should be retained, but
INT-CHAR and its shadow in the COERCE function should be removed.
This issue is unrelated to the apparent primary goal of the proposal.
Issue: CHARACTER-TYPE-RESTRICTIVEC
Define BASE-CHARACTER as a subtype of STRING.
No. Yes to BASE-CHARACTER as a subtype of CHARACTER.
Standard characters are a subset of the base
characters.
Yes.
STANDARD-CHAR type is replaced by (CHARACTER :STANDARD)
No. Keep STANDARD-CHAR. A change here is unnecessary for the rest of
the proposal. Adding (CHARACTER :STANDARD) would be okay, not adding it
would also be okay.
Remove the semi-standard characters.
No. A change here is unnecessary for the rest of the proposal.
Issue: STRING-TYPE-RESTRICTIVE
Define STRING as a union type
Yes
STRING used as a type specifier for object creation
means (VECTOR CHARACTER)
Yes
All string functions operate as specified on any
string object except it is an error to insert
an extended character into a base string.
Yes. This is already required by the requirement on storing
into arrays in general.
Extend the COERCE function to allow coercion from
base string to extended string.
No, this feature is already present in CLtL, since any sequence
type can be coerced to any other sequence type.
Issue: STRING-TYPE-ABBREVIATIONS
Yes.
Issue: SIMPLE-STRING-TYPE-RESTRICTIVE
Define SIMPLE-STRING as a union type
Abstain. We want to understand the consequences of this better,
vis a vis the alternative of defining SIMPLE-STRING as a
particular type, either (AND SIMPLE-ARRAY GENERAL-STRING)
or (AND SIMPLE-ARRAY BASE-STRING).
Define SIMPLE-STRING as a type specifier for object
creation means (SIMPLE-ARRAY CHARACTER (size))
Depends on the outcome of the previous.
Issue: SIMPLE-STRING-TYPE-ABBREVIATIONS
Add SIMPLE-BASE-STRING
Add SIMPLE-GENERAL-STRING
Depends on the outcome of the previous. This is getting to
be too many names.
Issue: FILE-EXTERNAL-REPRESENTATION
Add :EXTERNAL-CODED-CHARACTER-FORMAT keyword to OPEN
Approved in principle, but the name is too long.
Issue: CHAR-CODE-NON-PORTABLE
Add CHAR-CCS-VALUE function
Approved in principle, but the name is too long, uses an unmotivated
abbreviation "ccs", and is not consistent with the name of the OPEN
keyword. Although they don't do exactly the same thing (the OPEN
keyword can specify multiple coded character sets and a protocol
for switching among them), they are related enough that the names
should express their relation.
This issue is unrelated to the apparent primary goal of the proposal.
For both of the above, the main naming problem seems to be to keep
clear the distinction between these and CHAR-CODE. How about
CHAR-EXTERNAL-CODE for the function name and :EXTERNAL-CODE for
the OPEN keyword? These aren't the best names in the world, but
they are an improvement, maybe someone else can think of something
better.
Also this seems to be an incomplete set of facilities. Conversion
of characters to external codes is provided, but not the inverse.
Conversion between internal and external encodings is bundled with
stream I/O, but not available on its own; there could be functions
that convert a string to/from a vector of integers under a specified
"external-coded-character-format".
Issue: STRING-BINARY-WIDTH
Add EXTERNAL-CODED-STRING-LENGTH function
No. The meaning of what this returns is too implementation-dependent
and the need for this has not been shown. If this is retained, the name
should be consistent with the names of the preceding two facilities.
This issue is unrelated to the apparent primary goal of the proposal.
Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
Introduce the concept of Registries
We incline towards yes, except that the relation to ISO work has not
been made clear. In particular, how can registries be used before the
putative ISO committee is formed and completes its work?
Standardize on #\registry:id
Yes, assuming we guessed correctly what this was supposed to mean.
add all-implemented-registries
Add *ALL-CHARACTER-REGISTRY-NAMES* variable
Yes to one, no to the other. The second name is better.
Add FIND-CHAR function
Add CHAR-LABEL function
Add CHAR-REGISTRY-NAME function
Yes to these three.
New syntax for CHARACTER type specifier
New argument to CHARACTERP
No, the need for these has not been shown. Why not
call the CHAR-REGISTRY-NAME function?
New #\label:registry character name syntax
No, contradicts #\registry:id just above.
Is this issue unrelated to the apparent primary goal of the proposal?
That's the big question, isn't it? A more constructive way to put the
question is, how would a program make use of character registries to
access portably characters outside of the 96 characters that all Common
Lisp implementations must have? The proposal appears to be completely
silent on that point. We think we know how character registries would
actually be very useful for that. However, instead of counting on the
reader to guess the usefulness of character registries, the proposal
should contain some examples. If the character committee can't come up
with any examples, then perhaps character registries aren't really
needed.
∂06-Mar-89 1714 X3J13-mailer Review schedule reminder
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 17:13:56 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551816; Mon 6-Mar-89 20:11:10 EST
Date: Mon, 6 Mar 89 20:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Review schedule reminder
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902271052.AA15941@decwrl.dec.com>
Message-ID: <19890307011058.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 27 Feb 89 05:31
From: chapman%aitg.DEC@decwrl.dec.com
Please let me know if you have any trouble accessing or reviewing this
information.
I am not equipped to do anything with the tex source files you've been
mailing out. So far I have been unable to open a network connection
to hudson.dec.com to access the dvi file.
∂07-Mar-89 0254 X3J13-mailer clarification
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 7 Mar 89 02:54:26 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA06496; Tue, 7 Mar 89 02:52:25 PST
Message-Id: <8903071052.AA06496@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA06496; Tue, 7 Mar 89 02:52:25 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 7 Mar 89 05:47
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: clarification
In Symbolics' vote, Moon mentioned that he wasn't willing to vote on the
sections on the letter ballot because he was afraid they would be cast
in concrete. I should have made it more clear that these sections can
be changed, via clean-up, after they have been voted on.
I am trying to get incremental closure on the standard, just as one would
stop gratuitous changes on software being developed in a large system
a few modules at a time. That never means that the modules originally
"fixed" will not be subject to change if the whole system doesn't work!
Please do not be afraid to spend time reviewing these sections now and
commenting if there are problems. Even if the volume of reading looks
large, imagine how large it will look in a few months when you have
over 1000 pages to review.
Please review and vote!!!
kc
∂07-Mar-89 1334 X3J13-mailer hotel for march meeting
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Mar 89 13:34:03 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03677g; Tue, 7 Mar 89 13:27:16 PST
Received: by challenger id AA28084g; Tue, 7 Mar 89 13:22:41 PST
Date: Tue, 7 Mar 89 13:22:41 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8903072122.AA28084@challenger>
To: x3j13@sail.stanford.edu
Subject: hotel for march meeting
I have reserved rooms for X3J13 but it is up to you to make your personal
reservations.
---jan---
∂07-Mar-89 1403 X3J13-mailer Agenda DRAFT
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Mar 89 14:03:22 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03717g; Tue, 7 Mar 89 13:56:36 PST
Received: by challenger id AA28137g; Tue, 7 Mar 89 13:52:01 PST
Date: Tue, 7 Mar 89 13:52:01 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8903072152.AA28137@challenger>
To: x3j13@sail.stanford.edu
Subject: Agenda DRAFT
X3J13 Committee Meeting Agenda DRAFT
March 28 - 30, 1989
Fairfax, VA
1 Call to Order, Tuesday, March 28, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Other Business
6 Cleanup Subcommittee Report, Larry Masinter
7 Coffee Break 10:30
8 Cleanup Subcommittee Report continuation
9 LUNCH 12:00
10 Cleanup Subcommittee Report continuation
11 Recess, 5:00pm
12 Call to Order, Wednesday, March 29, 9:00am
13 Character Subcommittee Report, Thom Linden (4 hours)
14 Coffee Break 10:30am
15 Character Subcommittee Report continuation
16 Lunch 12:00
17 Character Subcommittee Report continuation
18 Compiler Subcommittee Report, Sandra Loosemore (2 hours)
19 Break 3:00
20 Compiler Subcommittee Report continuation
21 Recess 5:00
22 Call to Order, Thursday, March 30, 9:00am
23 Editorial Subcommittee Report, Kathy Chapman (1.5 hours)
24 Coffee Break 10:30
25 Cleanup Subcommittee Report continuation
26 Lunch 12:00
27 Cleanup Subcommittee Report continuation
28 Break 3:00
29 Cleanup Subcommittee Report continuation
30 Adjournment 5:00pm
∂07-Mar-89 1429 X3J13-mailer registration list
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Mar 89 14:29:22 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03769g; Tue, 7 Mar 89 14:22:28 PST
Received: by challenger id AA28211g; Tue, 7 Mar 89 14:17:54 PST
Date: Tue, 7 Mar 89 14:17:54 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8903072217.AA28211@challenger>
To: x3j13@sail.stanford.edu
Subject: registration list
X3J13 Attendee Information
03/07/89
Name Institute Paid L1 L2 L3
David Bartley TI -0- y y y
Paul Beiser HP -0- y y y
Mary Boelk Johnson Controls, Inc. -0- y y y
Kathy Chapman DEC -0- - - -
Jeff Dalton University of Ediburgh -0- y y y
Patrick Dussud Lucid, Inc. -0- y y y
Dick Gabriel Lucid, Inc. -0- y y y
David Gray TI 50.00 y y y
Masayuki Ida Aoyama Gakuin University -0- y y
Gregor Kiczales Xerox Corp. -0- y y y
Dieter Kolb Siemans -0- y y y
Tim Koschmann Xerox -0- y y y
Aaron Larson Honeywell S&RC -0- y y y
Kevin Layer Franz, Inc. 50.00 y y y
Thom Linden IBM 50.00 y y y
David Loeffler MCC 50.00 y y y
Sandra Loosemore University of Utah -0- y y y
Barry Margolin Thinking Machines 50.00 y y y
Larry Masinter Xerox Corp. -0- y y y
Robert Mathis CONTEL -0- y y y
David Moon Symbolics -0- y y y
Cris Perdue Sun Microsystems -0- y y y
Dan Pierson Encore Computer -0- y y y
Kent Pitman Symbolics -0- y y y
Guy Steele Thinking Machines -0- y y y
Paul Tucker IBM -0- y y y
Walter van Roggen DEC -0- y y y
JonL White Lucid, Inc. -0- y y y
Jan Zubkoff Lucid, Inc. -0- y y y
∂08-Mar-89 0523 X3J13-mailer Issue: PLUS-ABNORMAL
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 8 Mar 89 05:22:59 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA27292; Wed, 8 Mar 89 05:21:03 PST
Message-Id: <8903081321.AA27292@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA27292; Wed, 8 Mar 89 05:21:03 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 8 Mar 89 08:20
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: PLUS-ABNORMAL
Sorry about that. Disregard that last issue. It should have been sent
to cl-cleanup.
∂08-Mar-89 0520 X3J13-mailer Issue: PLUS-ABNORMAL
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 8 Mar 89 05:20:36 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA27193; Wed, 8 Mar 89 05:18:36 PST
Message-Id: <8903081318.AA27193@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA27193; Wed, 8 Mar 89 05:18:36 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 8 Mar 89 08:18
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: PLUS-ABNORMAL
Issue: PLUS-ABNORMAL
References: +, ++, +++ (p. 325)
Category: CLARIFICATION
Edit history: 1-MAR-89, Version 1 by Chapman
Problem Description:
The description of +, ++, and +++
does not mention the possibility of abnornal termination of
the evaluation of the variable {\tt +}.
Are the values associated with {\tt ++},
and {\tt +++} are updated?
Proposal (PLUS-ABNORMAL:UPDATE)
If the evaluation of the variable {\tt +} is aborted for some reason,
then the values associated with {\tt ++},
and {\tt +++} are updated.
Rationale:
This clarification is primarily to establish the contents of these
variables in all cases.
Current Practice:
VAX Lisp updates the values.
Adoption Cost:
?
Benefits:
Disambiguity.
Conversion Cost:
?
Aesthetics:
None.
Discussion:
∂08-Mar-89 1649 X3J13-mailer February 21 Ballot
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Mar 89 16:49:01 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA05400g; Wed, 8 Mar 89 16:42:11 PST
Received: by challenger id AA00614g; Wed, 8 Mar 89 16:37:36 PST
Date: Wed, 8 Mar 89 16:37:36 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903090037.AA00614@challenger>
To: x3j13@sail.stanford.edu
Subject: February 21 Ballot
Here is Lucid's vote. There are two conditional acceptances. One is
because several of us are rewriting the error terminology yet again.
The other is section 6.1 where I want to look at the notation
introduced there once more. Also, there are some minor problems with
the rest of the section, (for example, fill pointers and pathnames
should be described somewhere else.) The sections on CLOS (1.8, 2.3,
2.4, 2.5) were put together by Kathy, Linda DeMichiel, and me, so I
think they're ok from the CLOS committee's point of view.
________________________________________________________________________
Issue or section name | Version | Y | I | A |
------------------------------------------------------------------------
CUT-OFF-DATES | 4 | Y | | |
------------------------------------------------------------------------
ERROR-TERMINOLOGY | 5 | | I | |
------------------------------------------------------------------------
FONTS | 2 | Y | | |
------------------------------------------------------------------------
TOC | 1 | Y | | |
------------------------------------------------------------------------
Section 1.8 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.3 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.4 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.5 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 6.1 | 5.8 | | I | |
------------------------------------------------------------------------
-rpg-
∂08-Mar-89 1741 X3J13-mailer Feb. 21 Letter Ballot: editorial issues
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Mar 89 17:41:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 553455; Wed 8-Mar-89 20:38:11 EST
Date: Wed, 8 Mar 89 20:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Feb. 21 Letter Ballot: editorial issues
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <19890306214441.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890309013751.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I'd like to change the Symbolics vote, since you told me two things
that none of us here knew before: that there will be an opportunity
for cleaning up these sections even after they are voted in now, and
that the CLOS sections had already been carefully reviewed by Gabriel
and that Gregor had said he was satisfied with them. As a result,
we're changing our vote on sections 2.3, 2.4, and 2.5 from I to Y.
The other three I votes should remain. For ERROR-TERMINOLOGY because
it seems to be actively changing, for section 1.8 because the section
is sketchy, and for section 6.1 because we haven't really understood
it yet. Section 6.1 looks fundamental, do you think it's important
to get a vote on it as soon as possible? If so, we at Symbolics could
try to concentrate our efforts there.
I'd also like to clarify the meaning of this paragraph of our reply:
The five numbered sections: We approve these in principle, but aren't
ready to cast them in concrete. We haven't had time to review them with
the extreme care warranted for a language standard, and don't know who
else, if anyone, has reviewed them that thoroughly.
This was certainly not meant to give the impression that we were
refusing to review this stuff! The problem is simply that except for
Pitman, who is on the editorial committee, no one here had seen any of
this before two weeks ago. Also as it happens it is an extremely busy
time for us right now. Two weeks would not enough time for a really
careful review even in slack times, but at the time it was impossible.
I personally plan to try to review the entire standard carefully, as
well as to browbeat several other people at Symbolics into doing careful
review of either the entire standard or selected sections for their
areas of expertise. That will take a significant amount of time, of
course, probably several months.
∂09-Mar-89 1340 X3J13-mailer Issue: SUBSETTING-POSITION
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:40:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554074; Thu 9-Mar-89 16:37:07 EST
Date: Thu, 9 Mar 89 16:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SUBSETTING-POSITION
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902200927.AA06837@decwrl.dec.com>
Message-ID: <19890309213655.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I support SUBSETTING-POSITION:NONE. I think that subsets are
a good idea, but I also think that the X3J13 process has no
chance at all of coming up with a subset that is useful to
anyone in the time available. Therefore I think the standard
should propose no subsets, but should not contain any statement
(unlike, I think, Ada) to the effect that subsets are forbidden
or a bad idea.
∂09-Mar-89 1345 X3J13-mailer Issue: EXTENTIONS-POSITION
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:45:26 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554086; Thu 9-Mar-89 16:42:43 EST
Date: Thu, 9 Mar 89 16:42 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTENTIONS-POSITION
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902242224.AA13754@decwrl.dec.com>
Message-ID: <19890309214233.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor EXTENSIONS-POSITION:DOCUMENTATION.
I oppose EXTENSIONS-POSITION:DISABLE because it mandates a
particular development environment feature, but Common Lisp
has avoided saying anything about development environments
since that is an area of extreme controversy.
Gabriel's position of standing mute would be okay with me.
∂09-Mar-89 1349 X3J13-mailer Issue: MACRO-AS-FUNCTION
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:49:18 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554092; Thu 9-Mar-89 16:46:30 EST
Date: Thu, 9 Mar 89 16:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MACRO-AS-FUNCTION
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8902242236.AA14651@decwrl.dec.com>
Message-ID: <19890309214619.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Why don't we just change PROG1 and PROG2 to functions, now that
we have clarified that functions evaluate their arguments in
left-to-right order?
∂09-Mar-89 1350 X3J13-mailer Issue: UNSOLICITED-MESSAGES (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:50:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554094; Thu 9-Mar-89 16:47:35 EST
Date: Thu, 9 Mar 89 16:47 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNSOLICITED-MESSAGES (Version 2)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8902242237.AA14750@decwrl.dec.com>
Message-ID: <19890309214725.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS is okay.
∂09-Mar-89 1352 X3J13-mailer Issue: UNSPECIFIED-DATATYPES (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:52:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554096; Thu 9-Mar-89 16:49:52 EST
Date: Thu, 9 Mar 89 16:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNSPECIFIED-DATATYPES (Version 2)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8902242237.AA14708@decwrl.dec.com>
Message-ID: <19890309214942.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I oppose UNSPECIFIED-DATATYPES:NO-EXCEPT-AS-EXPLICITLY-ALLOWED
on the grounds that it is unnecessary and that the problem it's
attempting to address (making it possible to check conformance
by machine) is impossible to solve.
∂09-Mar-89 1357 X3J13-mailer Issue: EXTRA-SYNTAX (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:57:48 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554101; Thu 9-Mar-89 16:55:10 EST
Date: Thu, 9 Mar 89 16:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTRA-SYNTAX (Version 4)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902271015.AA14142@decwrl.dec.com>
Message-ID: <19890309215459.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I oppose EXTRA-SYNTAX:NO. The rationale says
It would be very difficult for a program-analyzing-program to detect
such an extension. Non-portable programs could easily result.
I can't see what's hard about detecting use of additional syntax not
specified -- that seems to be the easiest to detect of any
nonconformance. To take the canonical example of extending IF to allow
more than three subforms, surely it is very easy for a
program-analyzing-program to detect an invocation of IF with more than
three subforms and complain that the program is non-conforming.
∂09-Mar-89 1406 X3J13-mailer Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 14:06:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554109; Thu 9-Mar-89 17:03:09 EST
Date: Thu, 9 Mar 89 17:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS (Version 3)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902271016.AA14193@decwrl.dec.com>
Message-ID: <19890309220257.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I oppose both proposals. The adoption cost is:
Implementors will be required to determine which parts of their
implementations are conforming and which parts aren't. Implementors
will have to provide a candidate list of exceptions to the editorial
committee.
The second sentence strikes me as a lot of extra work that will just
delay closure on the standard.
The stated benefits are:
It will be more possible to write portable programs. Also, future
standards will be less likely to make changes that are incompatible
with current implementations.
I don't believe in the first benefit. This issue does not affect the
ability to write portable programs in any significant way. It only
affects whether particular implementations are more or less useful as
development tools for checking conformance. I believe that development
tools for checking conformance are a valuable item for which market
demand exists, but are not within the purview of X3J13.
The second benefit is true. However there are a large number of other
ways that future standards could be incompatible with current
implementations, none of which have been ruled out. For example, any
implementation that makes symbols accessible to the USER package other
than symbols in the LISP package risks name conflicts with future
additions to the LISP package. It's simply a fact of life that any
extension might be incompatible with an eventual standard; pioneers can
never be sure that everyone will follow in their exact footsteps.
∂09-Mar-89 1433 X3J13-mailer Issue: EXTRA-SYNTAX (Version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Mar 89 14:33:19 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA06700g; Thu, 9 Mar 89 14:26:23 PST
Received: by challenger id AA02174g; Thu, 9 Mar 89 14:21:48 PST
Date: Thu, 9 Mar 89 14:21:48 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903092221.AA02174@challenger>
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: EXTRA-SYNTAX (Version 4)
The rationale says:
``It would be very difficult for a program-analyzing-program to detect
such an extension. Non-portable programs could easily result.''
In fact the error terminology says this about extending the syntax
when it's allowed:
``Implementations are permitted to define unambiguous extensions to
the syntax of the construct being described. No conforming code can
depend on this extension. Implementations are required to document
each such extension. All conforming code is required to treat the
syntax as meaningless.''
Thus, the only syntactic extensions allowed would be those that
program analysis programs could detect.
There are some cases where we wish to disallow extensions and some
cases where we don't care. DEFCLASS is an example of one place we wish
to keep people away from. If there are vastly more places where we
don't care, that should be the default. I think it would take a
careful editorial process to decide whether it's easier to defaultly
allow or defaultly disallow. I think this issue is quite different
from that of extensions in general.
-rpg-
∂09-Mar-89 1539 X3J13-mailer Re: Issue: UNSPECIFIED-DATATYPES (Version 2)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 Mar 89 15:39:49 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA04997; Thu, 9 Mar 89 16:37:40 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA10028; Thu, 9 Mar 89 16:37:35 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903092337.AA10028@defun.utah.edu>
Date: Thu, 9 Mar 89 16:37:28 MST
Subject: Re: Issue: UNSPECIFIED-DATATYPES (Version 2)
To: chapman%aitg.dec@decwrl.dec.com
Cc: x3j13@sail.stanford.edu,
David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 9 Mar 89 16:49 EST
I agree with Moon. Leaving the behavior undefined gives an
implementation permission to do anything it wants, including starting
WWIII. "Anything" ought to include defining some useful behavior for
the situation, such as asking me if I really want to launch the
missiles.
-Sandra
-------
∂12-Mar-89 1616 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Mar 89 16:16:40 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555408; Sun 12-Mar-89 19:14:06 EST
Date: Sun, 12 Mar 89 19:13 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNSOLICITED-MESSAGES
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8902242237.AA14750@decwrl.dec.com>
Message-ID: <890312191349.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
I agree that this is an important issue.
I am not sure I agree with the proposed solution -- partly because
I don't think it goes nearly far enough, and partly because I think the
wording for the place where it stops encourages might actually encourage
more `abuse' than currently exists.
I think it should be possible to know with certainly that calling EQ,
CONS, or even COMPILE, was not going to do I/O, at least in
the normal case. In exceptional cases, CONS might produce GC warnings
or COMPILE might produce compiler warnings, but never should COMPILE
type out anything like
Compiling FOO.
or should EQ type out
Performing EQ comparison of #<FOO 32> and #<BAR 17>.
Right now, nothing assures me of this and I find that disturbing.
This is the issue which I expected to `fix' this problem, and it does
not. In fact, its suggestion that it's ok to type such messages on
*TERMINAL-IO* may actually encourage what I consider to be an abominable
practice.
I would like it stated clearly that in the `normal situation' no
LISP function is permitted to do I/O unless the manual expressly
permits it.
Further, I think the current proposal permitting unsolicited messages
to go to *TERMINAL-IO* is a bad idea. I don't think unsolicited messages
should ever go directly to *TERMINAL-IO*. I am ammenable to them going to
documented streams which happen to have initial values that are synonym
streams to *TERMINAL-IO*, but
- I -don't- want them to be the standard CL streams, so I don't redirect
them by accident.
- I -do- want them to not be *terminal-io* so I can redirect them on
purpose.
Conceivably we could actually make a *JUNK-OUTPUT* which is initially a
synonym stream to *TERMINAL-IO*, but which is specially permitted to be
NIL to mean don't send the output anywhere, and we should say that all
unsolicited I/O has to go through there.
∂13-Mar-89 0714 X3J13-mailer cl-compiler mail
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 07:14:10 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA16287; Mon, 13 Mar 89 08:12:01 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02044; Mon, 13 Mar 89 08:11:59 -0700
Date: Mon, 13 Mar 89 08:11:59 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131511.AA02044@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: cl-compiler mail
I will be sending out the remaining batch of cl-compiler issues today.
I will also put FTP'able copies on host cs.utah.edu in directory
~ftp/pub/cl-compiler/pending. I'll send out a summary of issues when
I've gotten through them all.
It may be necessary for us to bring revised versions of some of these
proposals to the meeting. In particular, a few of them have been put
together at the last minute and haven't been reviewed thoroughly yet;
I've marked these as drafts so you'll be able to identify them. Any
comments or questions should be directed to cl-compiler@sail.stanford.edu.
-Sandra
∂13-Mar-89 0747 X3J13-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 07:47:01 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17004; Mon, 13 Mar 89 08:44:52 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02070; Mon, 13 Mar 89 08:44:48 -0700
Date: Mon, 13 Mar 89 08:44:48 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131544.AA02070@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Forum: Compiler
Issue: COMPILED-FUNCTION-REQUIREMENTS
References: CLtL p. 32, 76, 112, 143, 438-439
Issue FUNCTION-TYPE (passed)
Issue COMPILER-LET-CONFUSION
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue LOAD-TIME-EVAL (passed)
Issue COMPILE-ENVIRONMENT-CONSISTENCY
Category: CLARIFICATION
Edit History: V1, 3 Jan 1989 Sandra Loosemore
V2, 10 Jan 1989, Sandra Loosemore (additional proposal)
V3, 10 Feb 1989, Sandra Loosemore (new proposal)
V4, 11 Mar 1989, Sandra Loosemore (fix wording to agree
with other pending proposals)
Status: Ready for release
Problem Description:
There is confusion about what functions might be or must be of type
COMPILED-FUNCTION, and what attributes must be true of
COMPILED-FUNCTIONs. Is the distinction between COMPILED-FUNCTIONs and
other functions only one of representation, or can user programs infer
anything about COMPILED-FUNCTIONs? Are implementations required to
distinguish between compiled and non-compiled functions?
CLtL defines a COMPILED-FUNCTION as "a compiled code object". (Issue
FUNCTION-TYPE says only that COMPILED-FUNCTION must be a subtype of
FUNCTION.) Although it is not explicitly stated, CLtL implies that
compiled code must conform to certain rules; in particular, it states
that all macros are expanded at compile time, and specifies different
behavior for the COMPILER-LET and the EVAL-WHEN special forms
depending on whether they are interpreted or compiled.
The description of COMPILE in CLtL says that "a compiled-function object
[is] produced". It is not clear to everyone whether this implies that
COMPILED-FUNCTION-P must be true of such functions. CLtL says nothing
about whether functions defined in files compiled with COMPILE-FILE and
subsequently loaded must be of type COMPILED-FUNCTION.
The two proposals presented below present a simple model of the
compilation process. A minimal compiler could be implemented to
perform a code walk to apply the indicated transformations to the
function source code. Of course, most compilers will perform other
transformations as well, such as translating the Lisp source code into
a representation that is more compact or which can be executed more
efficiently.
Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN:
(1) Clarify that if a function is of type COMPILED-FUNCTION, the
following are guaranteed about the function:
- All macro calls appearing lexically within the function have
already been expanded and will not be expanded again when the
function is called. (See CLtL p. 143.) The process of
compilation effectively turns MACROLET and SYMBOL-MACROLET
constructs into PROGNs with all instances of the local macros
in the body fully expanded.
- The compiler must capture declarations to determine whether
variable bindings and references appearing lexically within
the function are to be treated as lexical or special.
- COMPILER-LETs nested lexically within the function will not bind
any variables when the function is called (CLtL p. 112). Again,
the process of compilation effectively turns COMPILER-LET
constructs into PROGNs with all macros in the body fully expanded.
- Lexically nested EVAL-WHENs have been processed as stated in
proposal EVAL-WHEN-NON-TOP-LEVEL; either the body is treated as
an implicit PROGN or as the constant NIL.
- If the function contains lexically nested LOAD-TIME-VALUE forms,
these have already been pre-evaluated and will not be evaluated
again when the function is called.
(2) Implementations are free to classify all functions as
COMPILED-FUNCTIONs, provided that all functions satisfy the criteria
listed in item (1). It is also permissible for functions that are
not COMPILED-FUNCTIONs to satisfy the above criteria.
(3) Clarify that COMPILE always produces an object of type
COMPILED-FUNCTION. Clarify when functions are defined in a
file which is compiled with COMPILE-FILE, and the compiled file is
subsequently LOADed, objects of type COMPILED-FUNCTION result.
Rationale:
This proposal allows users to count on COMPILE and COMPILE-FILE always
producing objects that are COMPILED-FUNCTION-P.
It assigns some specific properties to compiled functions. Users would
be able to rely on any function which is of type COMPILED-FUNCTION having
really been (at least partially) compiled.
It also states what many people believe to be the minimum functionality
required of a compiler.
Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN-COMPILE:
(1) Clarify that functions produced by COMPILE, or defined in a file
produced by COMPILE-FILE which has been subsequently LOADed, must
satisfy the same requirements listed in section (1) of proposal
TIGHTEN.
(2) Clarify that COMPILE always produces an object of type
COMPILED-FUNCTION. Clarify when functions are defined in a
file which is compiled with COMPILE-FILE, and the compiled file is
subsequently LOADed, objects of type COMPILED-FUNCTION result.
Rationale:
This proposal allows users to count on COMPILE and COMPILE-FILE always
producing objects that are COMPILED-FUNCTION-P.
It also states what many people believe to be the minimum functionality
required of a compiler.
However, it allows functions that have not been compiled also to be of
type COMPILED-FUNCTION. For implementations that do not use different
representations for interpreted and compiled functions, it would still
allow COMPILED-FUNCTION and FUNCTION to be synonymous, even if
interpreted functions do not satisfy the requirements for compilation.
Current Practice:
It appears that most implementations currently distinguish compiled
versus non-compiled functions on the basis of representation. It seems
unlikely that any implementation would have problems satisfying the
stated minimum requirements for compilation.
Lucid uses the same representation for both compiled and non-compiled
functions, except there is a bit in the header used to distinguish them.
A-Lisp uses the same representation for both compiled and interpreted
functions and currently labels them both as COMPILED-FUNCTION, but the
implementation of COMPILED-FUNCTION-P could be easily fixed to
distinguish "real" compiled functions.
On the TI Explorer, the COMPILE function can return an object of
either type COMPILED-FUNCTION or LEXICAL-CLOSURE, where the latter
consists of two components -- an environment and a COMPILED-FUNCTION.
There is confusion about whether microcoded functions should be
considered compiled or not.
Cost to implementors:
Unknown, but probably small for either proposal. Proposal
TIGHTEN-COMPILE is probably most consistent with current practice.
Cost to users:
Probably minimal. Since the COMPILED-FUNCTION type specifier is
currently ill-defined, it is hard to imagine that existing programs
can portably rely on any interpretation of what it means that is
inconsistent with what is presented here.
Benefits:
The specification of what the compiler must do is made more explicit.
Discussion:
The FIXNUM and BIGNUM types were also defined in CLtL solely on the
basis of distinguished representations, and that this definition has
proved inadequate for just about all portable usages of these type
specifiers. Defining COMPILED-FUNCTION solely on the basis of
distinguished representation seems like a bad idea.
David Gray notes:
We make good use of the type COMPILED-FUNCTION in our implementation,
but all of the accessor functions for objects of that type are
non-standard, which makes me wonder if it might be best to just remove
this type from the standard along with BIGNUM.
One use of the COMPILED-FUNCTION type is in declarations. A-Lisp and
Lucid, for example, can compile FUNCALL more efficiently if it can be
determined that the function is of type COMPILED-FUNCTION. However,
in order for such declarations to be really useful, there should be a
way to construct an object which is guaranteed to be of type
COMPILED-FUNCTION. Both of the proposals presented require COMPILE
and COMPILE-FILE to construct compiled functions.
Sandra Loosemore says:
I have a marginal preference for proposal TIGHTEN-COMPILE, since it
gives implementors more flexibility. To me it's more important that
COMPILE and COMPILE-FILE be guaranteed to do something, than that I
be able to test whether a function has had those things done to it.
∂13-Mar-89 0749 X3J13-mailer issue COMPILER-VERBOSITY, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 07:48:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17056; Mon, 13 Mar 89 08:46:44 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02078; Mon, 13 Mar 89 08:46:42 -0700
Date: Mon, 13 Mar 89 08:46:42 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131546.AA02078@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILER-VERBOSITY, version 6
Forum: Compiler
Issue: COMPILER-VERBOSITY
References: CLtL p. 438-329; 426
issue COMPILER-DIAGNOSTICS
Category: ENHANCEMENT
Edit History: V1, 25 Oct 1988, Sandra Loosemore
V2, 12 Dec 1988, Dan L. Pierson (add USE-CONDITIONS)
V3, 15 Dec 1988, Dan L. Pierson (expand on conditions)
V4, 21 Dec 1988, Dan L. Pierson (reword and clarify)
V5, 06 Jan 1989, Sandra Loosemore (update discussion)
V6, 26 Jan 1989, Sandra Loosemore (remove USE-CONDITIONS)
Status: Ready for release
Problem Description:
Implementations vary widely in the amount of information that is printed
out by COMPILE-FILE. In some situations, it would be useful to control
how much information is printed.
Proposal COMPILER-VERBOSITY:LIKE-LOAD:
Introduce special variables, *COMPILE-VERBOSE* and *COMPILE-PRINT*,
with implementation-dependent initial values.
Add :VERBOSE and :PRINT keyword arguments to the function
COMPILE-FILE, analogous to those for the function LOAD.
The :VERBOSE argument (which defaults to the value of
*COMPILE-VERBOSE*), if true, permits COMPILE-FILE to print a message
in the form of a comment to *STANDARD-OUTPUT* indicating what file is
being compiled and other useful information.
The :PRINT argument (which defaults to the value of *COMPILE-PRINT*),
if true, causes information about top-level forms in the file being
compiled to be printed to *STANDARD-OUTPUT*. Exactly what is printed
will vary from implementation to implementation, but nevertheless some
information will be printed.
Introduce a special variable *LOAD-PRINT*, which has an initial value of
NIL. State that the default value of the :PRINT argument to LOAD is
*LOAD-PRINT* (rather than NIL).
Rationale:
This proposal makes COMPILE-FILE behave like LOAD. There is already
some precedent for doing this (for example, issue COMPILE-FILE-PACKAGE,
which makes COMPILE-FILE as well as LOAD rebind *PACKAGE*).
Adding the *LOAD-PRINT* variable allows the printing of messages by
LOAD to be controlled either on a global or a per-call basis.
Current Practice:
COMPILE-FILE prints out progress messages in nearly all
implementations.
Lucid provides a :MESSAGES keyword argument to COMPILE-FILE, which can
either be a stream to send messages to, or NIL to suppress messages.
The default value is T, which sends messages to "the standard terminal
device".
On the TI Explorer, COMPILE-FILE displays the name of the function
being compiled when the option :VERBOSE T is given or special variable
COMPILER:COMPILER-VERBOSE is true. (In other words, they use :VERBOSE
to mean what this proposal says to use :PRINT for.)
Symbolics Cloe already has a *LOAD-PRINT* variable.
Cost to implementors:
This is an incompatible change for some implementations. While the
changes required should be conceptually simple, their implementation
may involve a significant amount of grunt work. At least two
implementations already provide some similar mechanism for suppressing
messages.
Cost to users:
Some (non-portable) user code may break in implementations where this
is an incompatible change.
No user code should be broken by the addition of the *LOAD-PRINT*
variable, since the default behavior for the :PRINT keyword to LOAD
is unchanged.
Benefits:
Users are given a portable way to control how much information is printed
by COMPILE-FILE.
Discussion:
This issue addresses an extension to the language. If this proposal
is not accepted, the standard will simply continue not to say anything
about whether COMPILE-FILE can print progress messages, or what stream
such messages are directed to.
∂13-Mar-89 0748 X3J13-mailer issue COMPILER-DIAGNOSTICS, version 9
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 07:48:14 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17028; Mon, 13 Mar 89 08:46:02 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02075; Mon, 13 Mar 89 08:45:59 -0700
Date: Mon, 13 Mar 89 08:45:59 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131545.AA02075@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILER-DIAGNOSTICS, version 9
Forum: Compiler
Issue: COMPILER-DIAGNOSTICS
References: CLtL p. 438-439, 62, 69, 160, 161
Condition System, Revision #18
S:>KMP>cl-conditions.text.34
Issue GC-MESSAGES
Issue RETURN-VALUES-UNSPECIFIED
Issue COMPILER-VERBOSITY
Category: CLARIFICATION, ENHANCEMENT
Edit History: V1, 15 Oct 1988, Sandra Loosemore
V2, 19 Oct 1988, Sandra Loosemore (minor fixes)
V3, 25 Oct 1988, Sandra Loosemore (input from Pitman & Gray)
V4, 01 Nov 1988, Sandra Loosemore (fix typos)
V5, 15 Dec 1988, Dan L. Pierson (new condition types)
V6, 15 Dec 1988, Sandra Loosemore (additions, fix wording)
V7, 16 Dec 1988, Dan L. Pierson (minor cleanup)
V8, 07 Jan 1989, Sandra Loosemore (expand discussion)
V9, 26 Jan 1989, Sandra Loosemore (simplify)
Status: Ready for release
Problem Description:
It is unclear whether various diagnostics issued by the compiler are
supposed to be true errors and warnings, or merely messages.
In some implementations, COMPILE-FILE handles even serious error
situations (such as syntax errors) by printing a message and then
trying to recover and continue compiling the rest of the file, rather
than by signalling an error. While this user interface style is just
as acceptable as invoking the debugger, it means that a normal return
from COMPILE-FILE does not necessarily imply that the file was
successfully compiled.
Many compilers issue warnings about programming style issues (such as
binding a variable that is never used but not declared IGNORE).
Sometimes these messages obscure warnings about more serious problems,
and there should be some way to differentiate between the two. For
example, it should be possible to suppress the style warnings.
Also, neither CLtL nor issue RETURN-VALUES-UNSPECIFIED states what the
return value from COMPILE-FILE should be.
Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:
(1) Introduce a new condition type, STYLE-WARNING, which is a subtype
of WARNING.
(2) Clarify that ERROR and WARNING conditions may be signalled within
COMPILE or COMPILE-FILE, including arbitrary errors which may
occur due to compile-time processing of (EVAL-WHEN (COMPILE) ...)
forms or macro expansion.
Considering only those conditions signalled -by- the compiler (as
opposed to -within- the compiler),
(a) Conditions of type ERROR may be signalled by the compiler in
situations where the compilation cannot proceed without
intervention.
Examples:
file open errors
syntax errors
(b) Conditions of type WARNING may be signalled by the compiler in
situations where the standard explicitly states that a warning must,
should, or may be signalled; and where the compiler can determine
that a situation that "is an error" would result at runtime.
Examples:
violation of type declarations
SETQ'ing or rebinding a constant defined with DEFCONSTANT
calls to built-in Lisp functions with wrong number of arguments
or malformed keyword argument lists
referencing a variable declared IGNORE
unrecognized declaration specifiers
(c) The compiler is permitted to signal diagnostics about matters of
programming style as conditions of type STYLE-WARNING. Although
STYLE-WARNINGs -may- be signalled in these situations, no
implementation is -required- to do so. However, if an
implementation does choose to signal a condition, that condition
will be of type STYLE-WARNING and will be signalled by a call to
the function WARN.
Examples:
redefinition of function with different argument list
unreferenced local variables not declared IGNORE
declaration specifiers described in CLtL but ignored by
the compiler
(3) Require COMPILE and COMPILE-FILE to handle the ABORT restart by
aborting the smallest feasible part of the compilation. State that
both COMPILE and COMPILE-FILE are allowed to establish a default
condition handler. If such a condition handler is established,
however, it must first resignal the condition to give any
user-established handlers a chance to handle it. If all user error
handlers decline, the default handler may handle the condition in an
implementation-specific way; for example, it might turn errors into
warnings.
(4) Specify that COMPILE-FILE returns two values. The first value
is the truename of the output file, or NIL if the file could not be
created. The second value is T if the file was compiled without
errors, or NIL if errors were signalled during compilation.
Rationale:
Introducing the STYLE-WARNING condition allows handlers to distinguish
between potentially serious problems and mere kibitzing on the part of
the compiler.
Requiring any condition handlers established by the compiler to resignal
the condition before proceeding with any implementation-specific action
gives user error handlers a chance to override the compiler's default
behavior. For example, the user error handler could invoke a restart
such as ABORT or MUFFLE-WARNING.
Requiring the compiler to handle the ABORT restart reflects what
several implementations already do (although probably not using this
mechanism). The intent of the wording is to allow an implementation
to abort the entire compilation if it is not feasible to abort a
smaller part.
Requiring a second success-p value to be returned from COMPILE-FILE
gives the user some indication of whether there were serious problems
encountered in compiling the file.
Test Case/Example:
Here is an example of how COMPILE-FILE might set up its condition
handlers. It establishes an ABORT restart to abort the compilation
and a handler to take implementation-specific action on ERROR
conditions. Note that INTERNAL-COMPILE-FILE may set up additional
ABORT restarts.
(defvar *output-file-truename* nil)
(defun compile-file (input-file &key output-file)
(let ((*output-file-truename* nil)
(errors-detected nil))
(with-simple-restart (abort "Abort compilation.")
(handler-bind ((error #'(lambda (condition)
(setq errors-detected t)
(signal condition)
...)))
(internal-compile-file input-file output-file)))
(values *output-file-truename*
errors-detected)))
Current Practice:
No implementation behaves exactly as specified in this proposal.
In VaxLisp, COMPILE-FILE handles most compile-time errors without
invoking the debugger. (It gives up on that top-level form and moves on
to the next one.) Instead of signalling errors or warnings, it simply
prints them out as messages.
In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters
serious problems. COMPILE-FILE returns the pathname for the output file.
Symbolics Genera usually tries to keep compiling when it encounters errors;
so does Symbolics Cloe.
On the TI Explorer, the compiler tries to catch most errors and turn
them into warnings (except for errors on opening a file), but the user
can change special variable COMPILER:WARN-ON-ERRORS to NIL if he wants
to enter the debugger on an error signalled during reading, macro
expansion, or compile-time evaluation. The true name of the output
file is returned as the first value. A second value indicates whether
any errors or warnings were reported.
IIM Common Lisp's compiler handles errors using a resignalling mechanism
similar to what is described here.
Cost to implementors:
The cost to implementors is not trivial but not particularly high. This
proposal tries to allow implementations considerable freedom in what
kinds of conditions the compiler must detect and how they are handled,
while still allowing users some reasonably portable ways to deal with
compile-time errors.
Cost to users:
This is a compatible extension. This proposal may cause users to see
some small differences in the user interface to the compiler, but
implementations already vary quite widely in their approaches. Some
users will probably have to make some minor changes to their code.
Adding the STYLE-WARNING type may cause conflicts with programs
already using that name.
Benefits:
Users are given a way to detect and handle compilation errors, which
would simplify the implementation of portable code-maintenance
utilities. The behavior of the compiler in error situations is made
more uniform across implementations.
Discussion:
The issue of whether the compiler may print normal progress messages
is discussed in detail in a separate issue, COMPILER-VERBOSITY.
∂13-Mar-89 0815 X3J13-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:15:04 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17983; Mon, 13 Mar 89 09:12:55 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02083; Mon, 13 Mar 89 09:12:49 -0700
Date: Mon, 13 Mar 89 09:12:49 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131612.AA02083@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue CONSTANT-COMPILABLE-TYPES, version 8
Forum: Compiler
Issue: CONSTANT-COMPILABLE-TYPES
References: CLtL pp. 56, 77-80, 324
Issue CONSTANT-MODIFICATION
Issue CONSTANT-CIRCULAR-COMPILATION
Issue CONSTANT-ARRAY-ATTRIBUTES
Issue QUOTE-SEMANTICS
Issue LOAD-OBJECTS
Category: CLARIFICATION, ADDITION
Edit history: 11/07/88, V1 by Cris Perdue
11/14/88, V2 by Cris Perdue
11/22/88, V3 by Cris Perdue
12/20/88, V4 by Cris Perdue
01/06/89, V5 by Sandra Loosemore (minor editorial
clarifications, expand discussion)
03/05/89, V6 by Cris Perdue (more response to comments,
especially from Moon and and from Loosemore)
03/05/89, V7 by Loosemore (more editorial tweaks)
03/13/89, V8 by Loosemore (discussion)
Status: Ready for release
Problem description:
CLtL does not specify what objects can be in compiled constants and it
does not say what relationship there is to be between the
constant passed to the compiler and the one that is established by
compiling and then loading its file. Relevant remarks in CLtL
concerning file compilation and the definition of QUOTE suggest that
the compiler handles constants in ways that are not actually possible.
Introduction to the proposal:
The proposal CONSTANT-COMPILABLE-TYPES:SPECIFY attempts to spell out
what types can appear in compiled constants, and what it means when
they appear. Unless stated otherwise, in this proposal where the term
"constant" is used, it means a quoted or self-evaluating constant, not
a named (defconstant) constant.
The key is a definition of a form of equivalence between Lisp objects,
"similarity as constants". Code passed through the file compiler and
then loaded must behave as though quoted constants in it are "similar"
to quoted constants in the corresponding interpreted "source" code.
Because it is legitimate to compile in one address space and load into
a different one, it is necessary for the constraints to be defined
across address spaces. This proposal only concerns quoted constants
to be processed by COMPILE-FILE. Some other issues related to file
compilation are CONSTANT-COLLAPSING, CONSTANT-CIRCULAR-COMPILATION,
and QUOTE-SEMANTICS.
Some implementations "lose information" about some constants during
compilation. Typically all constant arrays become simple arrays
during the process of compiling and loading. We try to balance the
desire for more functionality against the effort required from
implementors.
Comments within the text of the proposal are enclosed in double angle
brackets, <<like this>>.
Proposal: CONSTANT-COMPILABLE-TYPES:SPECIFY
An object may be used as a quoted constant processed by COMPILE-FILE
if the compiler can guarantee that the resulting constant established
by loading the compiled file is "similar as a constant" to the
original. Treatment of uninterned symbols must be consistent across
the entire file as described below. There also is a constraint on
arrays which is not symmetrical; compilation can make arrays
"simpler", but not "less simple". (See below for the definition.)
We refer below to "quoted constants" or just "constants". In this
section these terms refer to objects appearing in expressions of the
form (QUOTE <object>), to objects used as self-evaluating forms, and
to objects appearing in code at locations described as "not
evaluated".
Some types such as streams are not supported in constants. Put
another way, an object containing one of these is not considered
similar as a constant to any other object. Some implementations may
support them and define how they are treated. For any object that
appears in a constant, but is not supported by the language as part of
a constant, the behavior of the compiler is unspecified; either the
the compiler and/or loader will handle that constant (in an
implementation-dependent manner) or the compiler will detect the
situation and signal an error.
Of the types supported in constants, some are treated as aggregate
objects. For these types, being similar as constants is defined
recursively. We say that an object of these types has certain
attributes, and to be similar as a constant to another object, the
values of the corresponding attributes of the two objects must also be
similar as constants.
This kind of definition has problems with any circular or "infinitely
recursive" object such as a list that is an element of itself. We
use the idea of depth-limited comparison, and say that two
objects are similar as constants if they are similar at all finite
levels. This idea is implicit in the definitions below, and applies
in all the places where attributes of two objects are required to be
similar as constants.
Here we define the notion of two objects being "similar as constants",
organizing the definition by type, and note additional constraints
that the compiler and loader working together must meet:
Number
If either of the two objects is a number, both must be of the same
type and must represent the same mathematical value.
Character
If either of the two objects is a character, both must be character
objects that represent the same character. <<Note that this
definition has to depend on the results of the Character Set
proposals.>>
Random-state
Let us say that two random-states are functionally equivalent if
applying RANDOM to them repeatedly always produces the same
pseudo-random numbers in the same order.
Two random-states are similar as constants exactly if copies of them
made via MAKE-RANDOM-STATE are functionally equivalent.
Note that a constant random-state object cannot be used as the "state"
argument to the function RANDOM (because RANDOM side-effects this
data structure).
Symbol
A symbol can only be similar to a symbol. References to interned
symbols are "by name". <<See issue COMPILE-FILE-SYMBOL-HANDLING for
details.>>
If a symbol is not interned, i.e. its home package is NIL, it is
treated in a rather special way. To be similar as a constant to
another symbol, both symbols must be uninterned and have the same
name.
Constants that contain uninterned symbols have to satisfy an extra
constraint. Consider the set of places in a constant that refer to
the same (EQ) uninterned symbol. In any similar constant, the
corresponding places must also all be EQ -- no more places and no
fewer. Moreover, COMPILE-FILE must arrange for the EQness of all
constant uninterned symbols that appear in the file to be preserved,
even if they are referenced in separate constants.
Because hash keys can be aggregate objects and because we treat hash
tables as unordered sets of <key, value> pairs, similarity of hash
tables is more complex. See under "Hash Tables", below, for the
definition.
Package
A package can only be similar as a constant to a package. References
to packages are permitted in any constant. References to packages are
"by name": two packages are similar as constants when their names are
similar as constants. Within a Lisp "address space", packages with
the same name are EQ.
At load time, the package becomes the same as returned by
FIND-PACKAGE, given the package name. An error is signalled if no
package of that name exists at load time.
AGGREGATE TYPES
---------------
For each of the types listed below, if either object is of the given
type, the two objects are similar as constants exactly if the other is
of that type and the values of all of the specified attributes are
similar as constants.
The attributes listed here can be called the "Basic Attributes" of
objects of each of these types.
Cons CAR, CDR.
Array For 1-dimensional arrays:
LENGTH, ARRAY-ELEMENT-TYPE, and ELT for all legal indices.
For arrays of other dimensions:
ARRAY-DIMENSIONS, ARRAY-ELEMENT-TYPE, AREF for all legal
indices.
An array of type SIMPLE-ARRAY can only be similar as a
constant to an array of type SIMPLE-ARRAY. However, we
allow the file-compiler a bit of latitude here. Where
constants in source code are displaced, have fill
pointers, or are adjustable, constants in the code
resulting from compilation and loading are permitted to
lack any or all of these qualities.
Hash Table Keys and value pairs. The table's test is unchanged
also. If the file compiler is given a constant containing a
a hash table that has keys that are similar as
constants, the consequences are undefined.
Consider a hash table as an unordered set of key and
value pairs. Two hash tables are similar as constants
exactly if there is a one-to-one correspondence between
the key and value pairs of each and a one-to-one
correspondence between the uninterned symbols of each
such that the two keys of each corresponding pair are
similar as constants and the two values are also similar
as constants. The correspondence of uninterned symbols
must be consistent with the correspondence defined for
the entire set of constants in the file.
Pathname Each pathname component.
OTHER TYPES
-----------
Stream, Compiled-Function, Readtable, Generic-function, Method
Objects of these types are not supported in compiled
constants.
Function Only function constants that are not compiled-functions
and do not close over any (lexical) variables are
supported in compiled constants.
Two such functions are similar as constants if their
SOURCE-LAMBDA-EXPRESSIONs are similar as constants.
Structure, Standard-object
<<There is a cl-cleanup issue, LOAD-OBJECTS, pending
which proposes a mechanism for dealing with objects.>>
For structure instances with no method defined at compile
time for MAKE-LOAD-FORM, the slot values and the name of
structure type (a symbol reference) are recorded by the
compiler and reconstructed by the loader.
Examples:
If source code contains a constant that could PRINT as (#1=#:FOO
#2=#:FOO #1# #2#), the constant resulting from compiling and loading
that code would have to be PRINTable as (#1=#:FOO #2=#:FOO #1# #2#).
If we make a hash table H, set three variables A, B, and C to
different uninterned symbols named FOO, and enter keys and values as
follows:
(setf (gethash a h) b)
(setf (gethash b h) a)
(setf (gethash c h) c)
If H appears in a compiled constant, after compiling and loading it,
(let ((value (list)))
(maphash #'(lambda (x y) (push (list x y) value)) h)
value)
could print as
((#1=#:FOO #2=#:FOO) (#2# #1#) (#3=#:FOO #3#))
but not as
((#1=#:FOO #2=#:FOO) (#2# #3=#:FOO) (#3# #1#))
Rationale:
For the benefit of users, this proposal tries to define a fairly large
set of types that all Common Lisp implementations are to handle. It
also attempts to leave room for implementations to differ. Some
implementations have made opposing choices because the language
doesn't specify one over the other. Some implementations already
handle constants that this proposal defines as not legal in Common
Lisp programs, and that is useful to users of those systems.
Different implementors have different amounts of resources to apply to
their system, and implementations differ in their whole approach in
some cases.
This proposal appears to reflect user demand and appears not to exceed
the capabilities of most implementations of the language.
The proposal ensures that all references to the same uninterned symbol
within a file will all map to references to just one uninterned symbol
after compiling and loading. This is needed to support PCL.
Current practice:
>From Gail Zacharias (Nov 14): "Coral pretty much implements this
proposal (I think we currently coalesce hash table keys, but that's
just a bug that will be fixed). We also fasdump packages (using the
package name) and compiled functions (but not foreign functions). For
symbols, we dump the name, and if (roughly speaking) the symbol would
get printed with a package prefix, we also dump the package name and
load the symbol into that package (otherwise it gets loaded into the
current load-time package)."
>From David Gray (Nov 9): "The Explorer can compile constant functions,
read tables, and hash tables; an error is signalled for a stream. A
package object used to break the compiler but in release 5 it has been
fixed to generate instructions to call FIND-PACKAGE on the package
name at load time." (Nov 15): [The Explorer does not guarantee
retention of displaced-to and displaced-index-offset attributes.]
"The Explorer also does not currently support dumping closures (either
compiled or evaluated), although non-closure compiled functions can be
dumped."
>From David Moon (Jan 24): "Symbolics Genera current practice: aside
from some current bugs we have with circular structures of certain
types and with preserving the identity of CONSes under EQ, this is
more or less consistent with our current practice, if you made the
changes implied by my earlier comments. We preserve the :displaced-to
and :fill-pointer array attributes. I doubt that we do what the
proposal says for hash-tables, readtables, and random-states. We
support dumping compiled and interpreted functions, but not closures,
which in effect means we don't support dumping functions."
>From Sandra Loosemore (Mar 3): "UCL currently can handle only
constants that are of type number, character, symbol, cons,
simple-vector, or string (which it turns into simple-string). It
signals an error if an attempt is made to compile any other kind of
object as a constant."
Adoption cost:
Not known. Probably moderate or low -- for most implementations. The
cost would be to implementors rather than users since this part of the
language is currently underspecified. The author believes the cost
will be reasonable for KCL, an implementation where there is some
concern about this issue.
This proposal is close to compatible with the Franz, Lucid, Coral,
Texas Instruments, and Symbolics implementations. It is probably
compatible or nearly compatible with other "Lisp Machine"
implementations.
Benefits:
Users would be able to use aggregate objects in constants with
confidence about the behavior of their code.
Conversion cost:
Where this proposal *requires* different behavior than an existing
implementation, there is a conversion cost for users of that
implementation. It appears that this cost will be small, less than
the cost of leaving things unspecified.
Esthetics:
Since there is no adequate definition at present, a fuller definition
would be more esthetic.
Discussion:
This proposal does leave some user-visible attributes of objects
unspecified across the compile-and-load process, except that they must
be consistent with the attributes that must be retained. This
situation is a compromise between the desire for full specification on
the one hand, and on the other hand the desire to leave freedom for
different implementations to remain different and to support some
optimizations such as compacting hash tables and "simplifying" arrays.
Proposals will be entertained for tighter specification of datatypes
such as arrays.
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
Comparing functions semantically is intertwined with the specification
of what conforming programs and implementations are allowed to do.
This proposal does not attempt to do that since compiled functions are
not supported by this proposal in compiled constants.
The definition of similarity for random-states supports the
possibility of random states that are immutable because of being in
compiled constants.
Readtables need not be supported by an implementation. If a readtable
contains only symbols to represent functions, here is Cris Perdue's
suggested spec for similarity of readtables:
Character syntax type for each character in the table;
function for each readmacro character, mappings for
dispatch macros; whether terminating or nonterminating
for each readmacro.
Interest has been expressed by a number of people including users, in
support for user-definable "dumping" of CLOS objects and structure
instances. The cleanup issue LOAD-OBJECTS deals with this.
This subsumes the issue CONSTANT-ARRAY-ATTRIBUTES.
The main point of disagreement on this proposal over its handling
of constant functions.
Sandra Loosemore says:
I plan to submit an amendment to this proposal which would remove the
requirement that the compiler be able to dump non-compiled, non-closed
functions. The reason for removing this requirement is that there is
no way to portably construct an object which is guaranteed to be a
non-compiled, non-closed function. Note that implementations are
permitted to make all functions COMPILED-FUNCTIONs.
Dick Gabriel says:
I guess I pretty strongly object to leaving functions out of the list
of constants that can appear in compiled code. The part that's
disturbing is that such non-Lispy things like arrays, hashtables, and
pathnames get better treatment than functions, the most Lispy part of
Common Lisp. I wonder how many implementations will be forced to come
within an inch of the required functionality to implement a first-rate
CLOS?
The specification of the subset of functions that are acceptable as
compiled constants cannot be tested for within Common Lisp itself.
I suggest we ask implementors (Lucid included) to bite the bullet and
handle this case correctly. Won't our grandchildren appreciate us
treating Common Lisp like Lisp and not like PASCAL?
If we were to specify that all functions could appear as constants, we
would also need to clarify whether the closed-over variable bindings
become immutable, and also deal with whether bindings that are closed
over more than one function retain their uniqueness. Also, the cost
to implementors to add support for dumping non-interpreted functions
may be quite high.
∂13-Mar-89 0821 X3J13-mailer issue CONSTANT-CIRCULAR-COMPILATION, version 7
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:21:42 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18436; Mon, 13 Mar 89 09:19:31 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02090; Mon, 13 Mar 89 09:19:28 -0700
Date: Mon, 13 Mar 89 09:19:28 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131619.AA02090@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 7
Forum: Compiler
Issue: CONSTANT-CIRCULAR-COMPILATION
References: Issue CONSTANT-COLLAPSING
Issue QUOTE-SEMANTICS
Category: CLARIFICATION, ADDITION
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 14 Nov 1988, Cris Perdue
V3, 12 Dec 1988, Sandra Loosemore (merge versions 1 and 2)
V4, 03 Jan 1989, Sandra Loosemore (add PRESERVE-SHARING-ONLY)
V5, 06 Jan 1989, Sandra Loosemore (minor wording changes)
V6, 08 Feb 1989, Sandra Loosemore (replace FLAG with YES)
V7, 11 Mar 1989, Sandra Loosemore (error terminology)
Status: Ready for release
Problem Description:
CLtL does not specify whether constants containing circular or
recursive references may be compiled. It is also not clear whether
the compiler must preserve sharing of EQ substructures; that is, whether
subobjects that are EQ in the source code must remain EQ after being
compiled.
The proposals below apply to constants appearing in a file compiled by
COMPILE-FILE. If proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE
passes, then the same constraints would apply to all constants. The
minimal scope over which sharing would be required to be detected is
over a single call to EVAL or COMPILE.
In the proposals that follow, "preserving EQness" means that
subobjects that are EQ in the source code must remain EQ after being
compiled; that is, things don't get "less EQ" after compilation.
(Note that coalescing of constants implies that things may get "more
EQ".)
Proposal CONSTANT-CIRCULAR-COMPILATION:NO
State that the consequences are undefined if an object containing a
circular reference appears as a constant to be compiled. State that
the compiler is not required to preserve EQness of substructures.
Rationale:
This proposal would not require any existing implementation to change.
Disallowing portable programs from containing circular constants
allows compiled file loaders to use somewhat simpler implementation
strategies (for example, to build constants in a strict bottom-up
fashion).
Proposal CONSTANT-CIRCULAR-COMPILATION:PRESERVE-SHARING-ONLY
State that the consequences are undefined if an object containing a
circular reference appears as a constant to be compiled. State that
the compiler is required to preserve EQness of substructures within a
file compiled with COMPILE-FILE.
Rationale:
Disallowing portable programs from containing circular constants
allows compiled file loaders to use somewhat simpler implementation
strategies (for example, to build constants in a strict bottom-up
fashion).
Some programs (such as PCL) have come to depend on COMPILE-FILE
preserving the EQness of uninterned symbols, and it is cleaner
to require sharing to be preserved in general instead of making
symbols be a special case. Requiring sharing to be preserved still
allows loaders to build constants bottom-up.
Proposal CONSTANT-CIRCULAR-COMPILATION:YES
State that objects containing circular references may legitimately
appear as constants to be compiled. State that the compiler is
required to preserve EQness of substructures within a file compiled
with COMPILE-FILE.
Rationale:
Users seem to expect this functionality, and some implementations
already provide it.
Current Practice:
A-Lisp preserves EQness of substructures (since it makes an effort to
collapse isomorphic structures) but signals an error if an attempt is
made to compile a circular constant. PSL and Utah Common Lisp both
get stuck in an infinite loop if an attempt is made to compile a
reentrant structure. The TI Explorer compiler is able to reproduce
recursive lists and arrays, but currently hangs in a loop on a
circular list. Neither the Explorer nor Symbolics Genera 7.x detects
EQness of list CDRs. Lucid handles circular constants correctly.
Franz uses a flag to control whether or not to attempt to detect
circular constants. KCL handles circular structures, but only detects
sharing of top-level structure (it does not traverse constants to look
for shared substructure).
Cost to implementors:
We know of no implementation that would have to change under proposal
NO.
For proposal YES, some implementations would require sweeping
changes; in some cases a completely different dumper/loader strategy
would have to be implemented.
The cost of proposal PRESERVE-SHARING-ONLY would fall somewhere in
between.
Cost to users:
The situation now is that programs which depend upon circularity or
sharing of substructure being preserved by the compiler are already
nonportable. Proposal NO simply formalizes the status quo. Proposal
YES would offer users functionality that is currently not portable.
Benefits:
An area of ambiguity in the language is removed.
Discussion:
The issue of compiler speed is largely a red herring on this issue;
the overhead of detecting circularities is generally quite small. The
main question is whether we should require some implementations to
completely redo their compiler/loader interface in order to support
circular constants.
It has been argued that any "serious" implementation will support
circular constants anyway, because of customer demand. However, since
there appears to be only one implementation (Lucid) that now
implements proposal YES in its full generality, perhaps the demand for
this feature is not really all that strong.
Earlier drafts of this writeup contained a proposal FLAG which would
have added a variable *COMPILE-CIRCLE*, similar to *PRINT-CIRCLE*.
However, there were unresolved problems about what would happen if the
value of this variable were altered within the file being compiled,
and it was generally agreed that this proposal didn't have any
particular advantages over proposal YES and just introduced
unnecessary hairiness.
Since it is usually fairly simple to detect circular constants,
Loosemore would support an amendment to proposals NO and
PRESERVE-SHARING-ONLY to change the first sentence to read:
State that the consequences are unspecified if an object containing
a circular reference appears as a constant to be compiled.
Implementations must either correctly handle the circular reference
or signal an error.
This is similar to the language which is already used in proposal
CONSTANT-COMPILABLE-TYPES:SPECIFY.
∂13-Mar-89 0824 X3J13-mailer issue CONSTANT-COLLAPSING, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:24:21 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18594; Mon, 13 Mar 89 09:22:09 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02093; Mon, 13 Mar 89 09:22:05 -0700
Date: Mon, 13 Mar 89 09:22:05 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131622.AA02093@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue CONSTANT-COLLAPSING, version 5
Forum: Compiler
Issue: CONSTANT-COLLAPSING
References: CLtL p. 78, 87
Issue CONSTANT-MODIFICATION
Issue CONSTANT-COMPILABLE-TYPES
Issue EQUAL-STRUCTURE
Issue QUOTE-SEMANTICS
Category: CHANGE
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 12 Dec 1988, Sandra Loosemore
V3, 03 Jan 1989, Sandra Loosemore
V4, 06 Jan 1989, Sandra Loosemore
V5, 11 Mar 1989, Sandra Loosemore
Status: Ready for release
Problem Description:
CLtL states that an implementation is permitted to "collapse" or
coalesce constants appearing in code to be compiled if they are EQUAL.
The definition of EQUAL does not permit coalescing of more general
isomorphic data structures (such as arrays and structures), which is
often desirable.
Issue QUOTE-SEMANTICS deals with whether coalescing may be performed
only by COMPILE-FILE, or by COMPILE and EVAL as well. If proposal
QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE passes, then coalescing could be
performed on all constants.
CLtL says: "An object is considered to be a constant in code to be
compiled if it is a self-evaluating form or contained in a QUOTE
form".
Proposal CONSTANT-COLLAPSING:GENERALIZE:
State the an implementation is permitted to coalesce constants
appearing in code to be compiled if they are equivalent under the
relationship defined in proposal CONSTANT-COMPILABLE-TYPES:SPECIFY.
Rationale:
There is little reason why implementations should not be allowed to
perform more general collapsing of structures, since the arguments
against doing so also apply to collapsing of EQUAL structures, which
is already permitted. The arguments for coalescing of EQUAL structures
(primarily space reduction) also apply to coalescing of structures that
are equivalent under a more general coalescing predicate.
Current Practice:
Both PSL/PCLS and A-Lisp collapse isomorphic arrays and structures,
and certain other data types that are defined internally as structures
(RANDOM-STATEs, for example). Lucid Common Lisp also uses a more
general coalescing predicate than EQUAL.
Cost to implementors:
None. This extends the range of permitted behavior for
implementations but does not require any implementation to change.
Cost to users:
Programs that depend on objects not being coalesced except when they
are EQUAL may break under this proposal. The only way one would be
able to detect that coalescing has taken place is if objects that were
not EQ in the source file become EQ after compilation; accessors on
the objects would return the same values regardless of whether or not
coalescing has taken place.
Benefits:
Collapsing of isomorphic arrays may lead to significant memory savings
in some applications.
Discussion:
This proposal depends heavily on issue CONSTANT-COMPILABLE-TYPES.
Some people believe that if the definition of EQUAL weren't "broken",
there wouldn't be any need for this proposal.
There is no inherent reason why the "coalescing predicate" must be the
same as the relationship used by the compiler/loader to construct
equivalent copies of objects of constants, but making the same rules
be applied in both situations simplifies the language somewhat.
∂13-Mar-89 0840 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:40:09 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 11:34:05 EST
Date: Mon, 13 Mar 89 11:35 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: UNSOLICITED-MESSAGES
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: <890312191349.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890313163525.7.BARMAR@OCCAM.THINK.COM>
Date: Sun, 12 Mar 89 19:13 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
I agree that this is an important issue.
I am not sure I agree with the proposed solution -- partly because
I don't think it goes nearly far enough, and partly because I think the
wording for the place where it stops encourages might actually encourage
more `abuse' than currently exists.
I think it should be possible to know with certainly that calling EQ,
CONS, or even COMPILE, was not going to do I/O, at least in
the normal case.
Do progress notes in the wholine count as output? If not, why not? If
so, are you proposing that they be prohibited? In Genera, calling
COMPILE displays "Compiling <name>" in the wholine, and calling
READ-CHAR on a console stream displays "User Input" in the wholine. I
like these things, but I think it will be difficult to express this
distinction in general enough terms in the standard.
In exceptional cases, CONS might produce GC warnings
or COMPILE might produce compiler warnings, but never should COMPILE
type out anything like
Compiling FOO.
or should EQ type out
Performing EQ comparison of #<FOO 32> and #<BAR 17>.
Right now, nothing assures me of this and I find that disturbing.
Why is this problem unique to Lisp? Is there any wording in the C
standard that explicitly prohibits malloc() from causing output? I
doubt it, yet I don't think they find this disturbing.
I think market forces should be enough to prevent really silly
unsolicited messages, just as all serious Lisp implementations have a GC
even though CLtL never mentions it.
barmar
∂13-Mar-89 0834 X3J13-mailer issue LOAD-TIME-EVAL, version 11
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:34:06 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18990; Mon, 13 Mar 89 09:31:55 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02140; Mon, 13 Mar 89 09:31:50 -0700
Date: Mon, 13 Mar 89 09:31:50 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131631.AA02140@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue LOAD-TIME-EVAL, version 11
On this issue, we've come up with an improved version of the proposal that
was accepted at the January meeting.
Forum: Compiler
Issue: LOAD-TIME-EVAL
References: #, (p. 356), (EVAL-WHEN (LOAD) ...) (p. 69-70)
issue SHARP-COMMA-CONFUSION
Category: ADDITION
Edit history: 06-Jun-87, Version 1 by James Kempf
17-Jul-87, Version 2 by James Kempf
12-Nov-87, Version 3 by Pitman (alternate direction)
01-Feb-88, Version 4 by Moon
(from version 2 w/ edits suggested by Masinter)
06-Jun-88, Version 5 by Pitman
(fairly major overhaul, merging versions 3 and 4)
21-Sep-88, Version 6 by Moon (stripped down)
17-Oct-88, Version 7 by Loosemore (change direction again)
30-Dec-88, Version 8 by Loosemore (tweaks)
23-Jan-89, Version 9 by Loosemore (amendments)
02-Mar-89, Version 10 by Loosemore (new proposal)
11-Mar-89, Version 11 by Loosemore
Problem description:
Common Lisp provides reader syntax (#,) which allows the programmer
to designate that a particular expression within a program is to be
evaluated early (at load time) but to later be treated as a constant.
Unfortunately, no access to this capability is available to programs
which construct other programs without going through the reader.
Some computations can be deferred until load time by use of EVAL-WHEN,
but since EVAL-WHEN must occur only at toplevel, and since the nesting
behavior of EVAL-WHEN is quite unintuitive, EVAL-WHEN is not a general
solution to the problem of load-time computation of program constants.
Proposal R**2-NEW-SPECIAL-FORM was approved at the January 1989
meeting. After the meeting, some additional suggestions were made that
have been incorporated into proposal R**3-NEW-SPECIAL-FORM. The sections
of the two proposals that differ are marked with change bars in the margin.
Proposal (LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM):
Add a new special form, LOAD-TIME-VALUE, which has the following
contract:
LOAD-TIME-VALUE form &optional read-only-p [Special Form]
LOAD-TIME-VALUE provides a mechanism for delaying evaluation of <form>
until the expression is in the "runtime" environment.
If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, the compiler
| performs normal semantic processing such as macro expansion but
| arranges for the evaluation of <form> to occur at load time in a null
lexical environment, with the result of this evaluation then being
treated as an immediate quantity at run time. It is guaranteed that
the evaluation of <form> will take place only once when the file is
loaded, but the order of evaluation with respect to the "evaluation"
of top-level forms in the file is unspecified.
If a LOAD-TIME-VALUE expression appears within a function compiled
with COMPILE, the <form> is evaluated at compile time in a null lexical
environment. The result of this compile-time evaluation is treated as
an immediate quantity in the compiled code.
In interpreted code, <form> is evaluated (by EVAL) in a null
lexical environment, and one value is returned. Implementations which
implicitly compile (or partially compile) expressions passed to
EVAL may evaluate the <form> only once, at the time this
compilation is performed. This is intentionally similar to the
freedom which implementations are given for the time of expanding
macros in interpreted code.
| Note that, in interpreted code, there is no guarantee as to when
| evaluation of <form> will take place, or the number of times the
| evaluation will be performed. Since successive evaluations of the
| same LOAD-TIME-VALUE expression may or may not result in an evaluation
| which returns a "fresh" object, destructive side-effects to the
| resulting object may or may not persist from one evaluation to the
| next. It is safest to explicitly initialize the object returned by
| LOAD-TIME-VALUE, if it is later modified destructively.
| Implementations must guarantee that each reference to a
| LOAD-TIME-VALUE expression results in at least one evaluation of its
| nested <form>. For example,
| (DEFMACRO CONS-SELF (X)
| `(CONS ,X ,X))
| (CONS-SELF (LOAD-TIME-VALUE (COMPUTE-IT)))
| must perform two calls to COMPUTE-IT; although there is only one
| unique LOAD-TIME-VALUE expression, there are two distinct references
| to it.
|
| In the case of a LOAD-TIME-VALUE form appearing in a quoted expression
| passed to EVAL, each call to EVAL must result in a new evaluation of
| <form>. For example,
| (DEFVAR X 0)
| (DEFUN FOO () (EVAL '(LOAD-TIME-VALUE (INCF X))))
| is guaranteed to increment X each time FOO is called, while
| (DEFUN FOO () (LOAD-TIME-VALUE (INCF X)))
| may cause X to be evaluated only once.
The READ-ONLY-P argument designates whether the result can be considered
read-only constant. If NIL (the default), the result must be considered
ordinary, modifiable data. If T, the result is a read-only quantity
which may, as appropriate, be copied into read-only space and/or shared
with other programs. (Because this is a special form, this argument is
-not- evaluated and only the literal symbols T and NIL are permitted.)
Rationale:
LOAD-TIME-VALUE is a special form rather than a function or macro
because it requires special handling by the compiler.
Requiring the compiler to perform semantic processing such as macro
expansion on the nested <form>, rather than delaying all such processing
until load time, has the advantages that fewer macro libraries may need
to be available at load time, and that loading may be faster and result
in less consing due to macroexpansion. If users really want to delay
macroexpansion to load time, this can be done with an explicit call to
EVAL, e.g.
(LOAD-TIME-VALUE (EVAL '(MY-MACRO)))
Allowing the same LOAD-TIME-VALUE to cause its nested <form> to be
evaluated more than once makes simplifies its implementation in
interpreters which do not perform a preprocessing code walk. It also
makes the rules for the time of its processing analogous to those
for macro expansion.
This proposal explicitly does -not- tie LOAD-TIME-VALUE to the #,
read macro. Doing so would be an incompatible change to the definition
of #, (which is reliably useful only -inside- quoted structure,
while LOAD-TIME-VALUE must appear -outside- quoted structure in a
for-evaluation position).
The requirement that LOAD-TIME-VALUE expressions be evaluated once per
reference (rather than once per unique expression) prevents problems
that could result by performing destructive side-effects on a value
that is unexpectedly referenced in more than one place.
Proposal (LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM):
Add a new special form, LOAD-TIME-VALUE, which has the following
contract:
LOAD-TIME-VALUE form &optional read-only-p [Special Form]
LOAD-TIME-VALUE provides a mechanism for delaying evaluation of <form>
until the expression is in the "runtime" environment.
If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, the compiler
| performs its normal semantic processing (such as macro expansion and
| translation into machine code) on the form, but arranges for the
| execution of <form> to occur at load time in a null
lexical environment, with the result of this evaluation then being
treated as an immediate quantity at run time. It is guaranteed that
the evaluation of <form> will take place only once when the file is
loaded, but the order of evaluation with respect to the "evaluation"
of top-level forms in the file is unspecified.
If a LOAD-TIME-VALUE expression appears within a function compiled
with COMPILE, the <form> is evaluated at compile time in a null lexical
environment. The result of this compile-time evaluation is treated as
an immediate quantity in the compiled code.
In interpreted code, <form> is evaluated (by EVAL) in a null
lexical environment, and one value is returned. Implementations which
implicitly compile (or partially compile) expressions passed to
EVAL may evaluate the <form> only once, at the time this
compilation is performed. This is intentionally similar to the
freedom which implementations are given for the time of expanding
macros in interpreted code.
| If the same (compared with EQ) list (LOAD-TIME-VALUE <form>) is
| evaluated or compiled more than once, it is unspecified whether <form>
| is evaluated only once or is evaluated more than once. This can
| happen both when an expression being evaluated or compiled shares
| substructure, and when the same expression is passed to EVAL or to
| COMPILE multiple times. Since a LOAD-TIME-VALUE expression may be
| referenced in more than one place and may be evaluated multiple times
| by the interpreter, it is unspecified whether each execution returns
| a "fresh" object or returns the same object as some other execution.
| Users must use caution when destructively modifying the resulting
| object.
|
| If two lists (LOAD-TIME-VALUE <form>) are EQUAL but not EQ, their
| values always come from distinct evaluations of <form>. Coalescing
| of these forms is not permitted.
The READ-ONLY-P argument designates whether the result can be considered
read-only constant. If NIL (the default), the result must be considered
ordinary, modifiable data. If T, the result is a read-only quantity
which may, as appropriate, be copied into read-only space and/or shared
with other programs. (Because this is a special form, this argument is
-not- evaluated and only the literal symbols T and NIL are permitted.)
Rationale:
LOAD-TIME-VALUE is a special form rather than a function or macro
because it requires special handling by the compiler.
Requiring the compiler to perform semantic processing such as macro
expansion on the nested <form>, rather than delaying all such processing
until load time, has the advantages that fewer macro libraries may need
to be available at load time, and that loading may be faster and result
in less consing due to macroexpansion. If users really want to delay
macroexpansion to load time, this can be done with an explicit call to
EVAL, e.g.
(LOAD-TIME-VALUE (EVAL '(MY-MACRO)))
Allowing the same LOAD-TIME-VALUE to cause its nested <form> to be
evaluated more than once makes simplifies its implementation in
interpreters which do not perform a preprocessing code walk. It also
makes the rules for the time of its processing analogous to those
for macro expansion.
This proposal explicitly does -not- tie LOAD-TIME-VALUE to the #,
read macro. Doing so would be an incompatible change to the definition
of #, (which is reliably useful only -inside- quoted structure,
while LOAD-TIME-VALUE must appear -outside- quoted structure in a
for-evaluation position).
Allowing multiple references to the same LOAD-TIME-VALUE expression
to result in only one interpretation allows it to be specified more
cleanly. It also allows interpreters that do not perform a prepass
to cache LOAD-TIME-VALUE expressions.
Current Practice:
This is an addition to the language and has not yet been implemented.
Cost to Implementors:
In compiled code, (LOAD-TIME-VALUE <form>) is similar to
'#,<form>. Most implementations can probably make use of the same
mechanism they use to handle #, to handle LOAD-TIME-VALUE. Note that
#, does not currently provide a mechanism for dealing with
non-read-only-ness.
Implementing LOAD-TIME-VALUE in the interpreter should be fairly
straightforward, since one simply needs to evaluate the <form> in the
null lexical environment. Implementations that use a preprocessing
code walk in the interpreter to perform macro expansion could process
LOAD-TIME-VALUE forms at that time.
Some code-walkers would have to be taught about this new
special form. Such changes would likely be trivial.
Cost to Users:
Some code-walkers would have to be taught about this new
special form. Such changes would likely be trivial.
Benefits:
Users are given a mechanism that to force evaluation to be delayed
until load time that does not rely on a feature of the reader.
Discussion:
Earlier versions (up to version 7) of this proposal stated that
all semantic processing of the LOAD-TIME-VALUE form should be postponed
until load time.
The semantics of LOAD-TIME-VALUE would be simplified considerably if
the READ-ONLY-P argument were removed and destructive operations on
the result of evaluating <form> prohibited. However, some people feel
that the ability to destructively modify the value is an essential
feature to include.
"Collapsing" of multiple references to the same LOAD-TIME-VALUE
expression could be allowed for read-only situations, but it seems
like it would be more confusing to make it legal in some situations
and not in others.
A number of other alternatives have been considered on this issue,
including:
- A proposal for a new special form that would force evaluation of
the <form> to happen only once. This was rejected because of
implementation difficulties.
- A proposal to add a function making the "magic cookie" used by #,
available to user code. The current proposal does not prevent such
a function from being added, but this approach appeared to have
less support than making the hook available as a new special form.
- A proposal to remove #, entirely (issue SHARP-COMMA-CONFUSION).
- A suggestion to change the behavior of (EVAL-WHEN (LOAD) ...).
Kent Pitman says:
Although I'm willing to take multiple evaluation in the interpreter
as a compromise position, I would like it mentioned in the discussion
that this was only an expedient to getting this issue accepted at all,
and that I'm not really happy about it. I have said that I think a
number of our lingering problems (with EVAL-WHEN, COMPILER-LET, and
this -- for example) are due to the presence of interpreters which do
not do a semantic-prepass at a known time. If I had my way, we would
require a semantic pre-pass and we would then be able to forbid
multiple evaluations even in the interpreter.
Moon and Gray support proposal R**3-NEW-SPECIAL-FORM.
Pitman also expressed willingness to go along with
R**3-NEW-SPECIAL-FORM, but was somewhat concerned that coalescing
LOAD-TIME-VALUE results based on EQ-ness of the LOAD-TIME-VALUE form
could conceivably lead to trouble down the line. However, since he
could provide no actual examples to back up that worry, and since the
majority opinion was that some implementations would find a
restriction against such coalescing an undue burden, the decision was
made to just `note the concern' and proceed on. Sandra Loosemore and
JonL White concur with this position.
∂13-Mar-89 0853 X3J13-mailer issue COMPILER-VERBOSITY, version 6
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:53:16 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 11:48:42 EST
Date: Mon, 13 Mar 89 11:50 EST
From: Barry Margolin <barmar@Think.COM>
Subject: issue COMPILER-VERBOSITY, version 6
To: cl-compiler@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131546.AA02078@defun.utah.edu>
Message-Id: <19890313165001.9.BARMAR@OCCAM.THINK.COM>
I see the benefit of :PRINT, but do we really need :VERBOSE? What's the
difference between
(compile path :verbose t)
and
(format t "~&Compiling file ~A...~%" path)
(compile-file path)
(format t "~&done.~%")
If any users want to have this controlled by a global variable, they can
do what we (Thinking Machines) did years ago and package it up in their
own function. At this stage of the game I don't see the need to add
gratuitous features like this.
:PRINT is less gratuitous because it implements a feature that the user
can't add himself.
barmar
∂13-Mar-89 0855 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:54:56 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555652; Mon 13-Mar-89 11:51:33 EST
Date: Mon, 13 Mar 89 11:51 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNSOLICITED-MESSAGES
To: barmar@Think.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, chapman%aitg.DEC@decwrl.dec.com,
x3j13@sail.stanford.edu
In-Reply-To: <19890313163525.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <890313115113.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Mon, 13 Mar 89 11:35 EST
From: Barry Margolin <barmar@Think.COM>
Date: Sun, 12 Mar 89 19:13 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
I agree that this is an important issue.
I am not sure I agree with the proposed solution -- partly because
I don't think it goes nearly far enough, and partly because I think the
wording for the place where it stops encourages might actually encourage
more `abuse' than currently exists.
I think it should be possible to know with certainly that calling EQ,
CONS, or even COMPILE, was not going to do I/O, at least in
the normal case.
Do progress notes in the wholine count as output? If not, why not? ...
No. They are passive. The function in question does not output to the
wholine. Rather, it arranges information such that a foreign process
can access it and display it. For example, if 500 calls to LOAD are done
in three second, you don't always get 500 progress messages. That is
because the output is done by the foreign process doing the polling and
not the process which is running the CL code. I think this distinction
is important. Indeed, if the running process could block, signal an
error, etc. due to problems in I/O then it would not be a good idea.
If so, are you proposing that they be prohibited?
No.
In Genera, calling
COMPILE displays "Compiling <name>" in the wholine, and calling
READ-CHAR on a console stream displays "User Input" in the wholine.
No. COMPILE does no display. A foreign process which is working by polling
does. This is no different than a foreign process doing any kind of
debugging activity.
I like these things, but I think it will be difficult to express this
distinction in general enough terms in the standard.
I don't think it's that difficult.
In exceptional cases, CONS might produce GC warnings
or COMPILE might produce compiler warnings, but never should COMPILE
type out anything like
Compiling FOO.
or should EQ type out
Performing EQ comparison of #<FOO 32> and #<BAR 17>.
Right now, nothing assures me of this and I find that disturbing.
Why is this problem unique to Lisp? Is there any wording in the C
standard that explicitly prohibits malloc() from causing output? I
doubt it, yet I don't think they find this disturbing.
Maybe it's because C people have traditionally been willing to settle
for less. :-) Seriously, I think it's a clear hole in their standard.
People would probably flame if things that weren't documented as doing
I/O were to suddenly start doing it.
I think market forces should be enough to prevent really silly
unsolicited messages,
Really I don't. COMPILE is a notable offender. Real implementations have
been known to print "Compiling FOO." on *TERMINAL-IO* and this proposal
does not forbid it.
In some cases, market pressure can --- after some number of months --
get things back in line. In others, implementors just point to the standard
and either say "it doesn't say anything" or even worse suggest that the
reason it doesn't say it is because it wants to leave room.
Not all implementors come from our culture. Often, those that don't
would -prefer- to have little `hints' (rules?) like this specified so
that the process of making incidental decisions would be easier. For
example, it's not unreasonable that implementors find themselves asking
"Should COMPILE say something?" -- It's been traditional for compilers
in languages where you couldn't invoke the compiler at runtime to do
typeout, so they might naturally assume that the same should be true
here. Certainly it's natural for them to at least answer the question.
just as all serious Lisp implementations have a GC
even though CLtL never mentions it.
This comes up because it's a "hard issue" and new implementors naturally
tend to discuss "hard issues" with other implementors before even getting
started. My guess is that no new implementor would consider calling up
Moon or JonL or Masinter to ask what the I/O behavior of COMPILE should
be. Probably they would just make a guess, hope it was right, and move on
to the next seemingly trivial decision.
∂13-Mar-89 0853 X3J13-mailer issue MACRO-CACHING, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:49:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA19529; Mon, 13 Mar 89 09:47:42 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02151; Mon, 13 Mar 89 09:47:38 -0700
Date: Mon, 13 Mar 89 09:47:38 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131647.AA02151@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue MACRO-CACHING, version 2
Issue: MACRO-CACHING
Forum: Compiler
References: 8.2 Macro Expansion (CLtL pp151-152),
Issues PACKAGE-CLUTTER, LISP-SYMBOL-REDEFINITION,
QUOTE-SEMANTICS (a.k.a. QUOTE-MAY-COPY),
and MACRO-ENVIRONMENT-EXTENT
Category: Clarification
Edit history: 31-Jan-89, Version 1 by Pitman
11-Mar-89, Version 2 by Loosemore (add discussion)
Status: Ready for release
Background:
CLtL suggests that macro caching is a legitimate strategy.
Two particular kinds of caching are common:
Displacement. A macro expansion function displaces the actual macro in
order to avoid any later need for lookup.
Table. A macro expression is looked up in a cache (such as a hash table)
to avoid having to run the expander code.
While CLtL seems to expressly suggest these strategies to be legitimate,
linguistic constraints show that in most cases they are not. The problems
are things like:
- lexical scoping (MACROLET and SYMBOL-MACROLET, and FLET and LET to
the extent that they shadow the effect of MACROLET and SYMBOL-MACROLET,
respectively).
- ``read only'' structure
To see the problem, consider the following examples:
(SETQ FOO1 '(FOO))
(EVAL `(LIST (MACROLET ((FOO (&WHOLE FORM) '(+ 1 1))) ,FOO1)
(MACROLET ((FOO (&WHOLE FORM) '(+ 1 2))) ,FOO1)))
=> (2 3)
Note that because the lexical contour may vary for an EQL expression,
however, displacing the expansion will cause confusion:
(DEFUN DISPLACE (X Y)
(SETF (CAR X) (CAR Y))
(SETF (CDR X) (CDR Y))
X)
(DEFVAR FOO2 '(FOO))
(EVAL `(LIST (MACROLET ((FOO (&WHOLE FORM)
(DISPLACE FORM '(+ 1 1)))) ,FOO2)
(MACROLET ((FOO (&WHOLE FORM)
(DISPLACE FORM '(+ 1 2)))) ,FOO2)))
=> (2 2)
CLtL suggests that a displacement hook might be placed in
*MACROEXPANSION-HOOK*. The above example shows that to be an
unreliable technique.
If this were not enough, displacement is also inappropriate because
no Common Lisp primitive can tell the difference between regular list
structure and read-only list structure. Since a macro form being
expanded might have been read-only in some implementations (e.g., EVAL
of a quoted list), the macro cannot reliably side-effect the structure.
In the case of table-lookup, the problem is more complicated.
Table-lookup does not have a necessary effect beyond the particular
lookup being done at the moment. To do table-lookup correctly relies
on the key being not only the expression but also the lexical
environment object. Whether the cost of making and throwing away so
many tables was worth the savings over running the macro expander is
not at all clear. And the GC effects of caching every macro environment
ever seen may be extraordinary, however correctness could in principle
be preserved by doing such a two-dimensional lookup... at least unless
we decide that macro environments have only dynamic extent. [A separate
proposal, MACRO-ENVIRONMENT-EXTENT, addresses this issue. If it passed,
then there would really be no way for users to do reliable macro caching
without cooperation from the system to have the cache be part of the
environment itself.]
Problem Description:
Macro caching by displacement is provably not semantically valid.
Macro caching by table lookup is difficult for a user to do correctly,
and in any case is not possible to handle efficiently in user code.
Proposal (MACRO-CACHING:DISALLOW):
1. a. Clarify that macro caching by displacement is not semantically
valid in user code.
b. Clarify that macro caching by displacement is semantically valid
for system macros and special forms, provided that such caching
does not prejudice the expansion of user-code contained in any
displaced code. For example:
(PROG () (FOO))
could displace to a BLOCK, but the (FOO) must appear un-expanded
in the BLOCK in case the BLOCK occurs in more than one lexical
environment.
2. a. Clarify that macro caching by table lookup is not semantically
valid in user code in order to correctly respect the lexical
environment.
Implementations are free to extend the language to permit such
lookup and to offer functions which support it in a more efficient
way, but code using such functions would, of course, not be portable.
b. Clarify that macro caching by table lookup is valid for the system,
but only if it correctly respects the lexical environment.
Proposal (MACRO-CACHING:RESTRICT):
Like DISALLOW, but change 2a to:
Clarify that macro caching by table lookup is semantically valid only
if the lookup is keyed both on the form and the environment.
Implementations are free to extend the language to offer functions
which support it in a more efficient way, but code using such functions
would, of course, not be portable.
Rationale:
1. a. Displacement has effects which by their nature transcend
lexical boundaries.
b. The system can assure that lexical boundaries are irrelevant in some
cases because users are not permitted to redefine or shadow definitions
in the initial LISP system. [See issues PACKAGE-CLUTTER and
LISP-SYMBOL-REDEFINITION.]
2. a. Users can only associate an environment with a macro cache table
in a very clumsy way. Also, Permitting them to do so at all forces
macro environments to have indefinite extent, and works against
efficiency in compilers.
b. The system is capable of allocating space in an environment object
for a macro cache which can be reliably kept up in synch with the
lexical environment environment.
Test Case:
;; #1: File compiling this definition in some implementations will produce
;; a definition that returns read-only list structure. The call to EVAL
;; on the result must not try to modify the read-only structure during
;; macroexpansion. [See issue QUOTE-SEMANTICS.]
(DEFUN READ-ONLY-FOO () '(MACROLET ((FOO (&WHOLE FORM) (+ 1 1))) (FOO)))
(EVAL (READ-ONLY-FOO))
=> 2
;; #2: This constructs a form and then uses it in two places in another
;; constructed form. Each of the uses is in a different lexical
;; contour, so must be expanded differently.
(LET ((FOO (LIST 'FOO)))
(EVAL `(LIST (MACROLET ((FOO (&WHOLE FORM) '(+ 1 1))) ,FOO)
(MACROLET ((FOO (&WHOLE FORM) '(+ 1 2))) ,FOO))))
=> (2 3)
;; #3: This is effectively the same thing but involves a MACROLET
;; shadowing a DEFMACRO rather than two MACROLETs, since some
;; implementations might only be caching expansions that come
;; from DEFMACRO.
(DEFMACRO FOO (&WHOLE FORM) '(+ 1 1))
(LET ((FOO (LIST 'FOO)))
(EVAL `(LIST ,FOO (MACROLET ((FOO (&WHOLE FORM) '(+ 1 2))) ,FOO))))
=> (2 3)
Current Practice:
Symbolics Genera does not use displacing or table caching in either
the interpreter or compiler.
Symbolics Cloe, a compiled only implementation, uses table caching
to boost compilation by a little. Running the test cases above turned
up a bug (in test case #3), which is now in the process of being fixed.
[The fact that a bug was turned up in code written by a CL implementor
is an existence proof that the potential for trouble was not imagined.]
Both Symbolics Cloe and Symbolics Genera support *MACROEXPANSION-HOOK*,
leaving open the possibility of users bringing disasters upon themselves.
Macro environment objects in Symbolics Genera are stack-allocated, so
have only dynamic extent.
Cost to Implementors:
This proposal is upward compatible with correct implementations.
Cost to Users:
There is no cost to users of the RESTRICT proposal, unless they were doing
semantically invalid caching.
The cost to users of the DISALLOW proposal is a loss of speed in some cases
which are semantically valid. In general, however, the efficiency and
usefulness of such caching is subject to question in code intended to be
ported. Given that implementations are not required to ever give the same
environment object twice, the caching may be all for naught in some
implementations.
Cost of Non-Adoption:
Continued widespread confusion about whether displacement is a legitimate
implementation technique for user code.
Benefits:
Since *MACROEXPANSION-HOOK* is in the Lisp package, multiple applications
in the same environment share its effects. Often one application will
clobber another's hook, or introduce a hook that is not desirable to other
applications when none previously existed. Since a common use of
*MACROEXPANSION-HOOK* is to install a macro caching mechanism, clarifying
the situations in which *MACROEXPANSION-HOOK* should not be used will
decrease the likelihood of one program breaking, slowing down, or otherwise
adversely affecting another.
Aesthetics:
Most people agree that macro caching techniques are only supposed to improve
speed without affecting semantics. This proposal is only intended to
underscore that necessary truth. Insofar as this is only a clarification,
it presumably has no significant aesthetic impact.
Discussion:
Pitman thinks it's a good idea to clarify this issue because it's not really
spelled out now and it's the sort of thing programmers can waste a lot of
time bickering about to no good end. Either the functionality is reliable
and should be encouraged, or it is not reliable and should be discouraged
or forbidden. Pitman supports the DISALLOW proposal because it leaves open
the possibility of making macro environments have dynamic extent, but he
can live with the RESTRICT position, which he believes represents the
status quo.
Bob Laddaga (a Cloe maintainer who reviewed a draft of this proposal)
supports the DISALLOW option as well.
David Grays says:
I can accept MACRO-CACHING:DISALLOW.
The Explorer evaluator does displacement of macros, but is careful to
correctly handle the cases exemplified in your test cases #1 and #2.
It does not do the right thing for #3, but that is a bug that can fairly
easily be fixed.
Sandra Loosemore says:
This issue is closely tied to MACRO-ENVIRONMENT-EXTENT. If we decide
environments have (or can be made to have) indefinite extent, I see no
reason not to go with MACRO-CACHING:RESTRICT. On the other hand, if
we decide environments have only dynamic extent, proposal
MACRO-CACHING:DISALLOW is the only one that makes sense.
∂13-Mar-89 0924 X3J13-mailer issue QUOTE-SEMANTICS, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 09:23:57 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA20995; Mon, 13 Mar 89 10:21:38 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02184; Mon, 13 Mar 89 10:21:33 -0700
Date: Mon, 13 Mar 89 10:21:33 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131721.AA02184@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue QUOTE-SEMANTICS, version 2
This issue replaces QUOTE-MAY-COPY, which was distributed and discussed
briefly at the last meeting.
Forum: Compiler
Issue: QUOTE-SEMANTICS
Subsumes: Issue QUOTE-MAY-COPY
References: CLtL p. 55, 78, 86, 143
Issue CONSTANT-COLLAPSING
Issue CONSTANT-COMPILABLE-TYPES
Issue CONSTANT-CIRCULAR-COMPILATION
Category: CLARIFICATION
Edit History: V1, 22 Jan 1989, Sandra Loosemore
V2, 13 Mar 1989, Sandra Loosemore (discussion)
Status: Ready for release
Problem Description:
Is it permissible for COMPILE and EVAL to coalesce or copy constants?
Are there constraints upon what kinds of objects may appear as
constants in code processed by COMPILE or EVAL, similar to those for
COMPILE-FILE?
CLtL p86 states that (QUOTE <x>) simply returns <x>. On p55 it is
mentioned that the only self-evaluating forms that may be copied are
numbers or characters. It is also stated that an implementation is
permitted to collapse (or coalesce) EQUAL constants "appearing in code
to be compiled" (p78), which is defined to mean self-evaluating forms
or objects contained in a QUOTE form (without reference to whether the
form is processed by EVAL, COMPILE, or COMPILE-FILE).
Because of its nature as a file processor, COMPILE-FILE generally must
cause copies of constants to be constructed when the compiled code is
loaded. In a number of existing Lisp implementations, COMPILE also
causes constant objects to be copied and/or coalesced. There is also
at least one implementation where constants are copied by EVAL in some
circumstances.
Proposal QUOTE-SEMANTICS:NO-COPYING:
State that copying or coalescing of constants appearing in code
processed by EVAL and COMPILE is not permitted; the resulting program
must reference objects that are EQL to the corresponding objects in
the source code. The constraints on what kinds of objects may appear
as constants (described in issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION) apply only to COMPILE-FILE.
Rationale:
This proposal is consistent with what many people think of as the
"traditional" semantics for QUOTE. It gives users maximum flexibility
about what kinds of objects may appear as constants.
Proposal QUOTE-SEMANTICS:COPYING-ALLOWED-BUT-NO-CONSTRAINTS:
State that copying or coalescing of constants appearing in code
processed by EVAL and COMPILE is permitted. Copying or coalescing may
only take place when the source code is "promoted" to being a program
by EVAL or COMPILE, not at runtime. Function definitions are promoted
to being a program when the form enclosing the definition (e.g., a
FUNCTION or DEFUN form) is promoted.
Any object may validly appear as a constant in code processed by EVAL
or COMPILE. The constraints on what kinds of objects may appear as
constants (described in issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION) apply only to COMPILE-FILE.
Rationale:
This proposal is the most consistent with the semantics stated in CLtL.
It gives users maximum flexibility about what kinds of objects may
appear as constants.
Proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE:
State that copying or coalescing of constants appearing in code
processed by EVAL and COMPILE is permitted. Copying or coalescing may
only take place when the source code is "promoted" to being a program
by EVAL or COMPILE, not at runtime. Function definitions are promoted
to being a program when the form enclosing the definition (e.g., a
FUNCTION or DEFUN form) is promoted.
The constraints on what kinds of objects may appear as constants
(described in issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION) apply to EVAL and COMPILE as well as to
COMPILE-FILE.
Rationale:
This makes the rules for handling of constants consistent between
EVAL, COMPILE, and COMPILE-FILE. It gives implementors maximum
flexibility in handling constants in EVAL and COMPILE.
Current Practice:
Implementations in which COMPILE attempts to copy all constants
include PSL/PCLS and Kyoto Common Lisp.
In Lucid Common Lisp, constants are not normally copied by COMPILE,
but since COMPILE does coalesce constants, it may cause QUOTE to
return an object which is not EQL to the object which appeared in the
source code.
Symbolics Genera has COMPILE copy list, string, non-displaced array,
and (I-Machine only) closure constants, but Moon says he thinks this
is wrong.
There is known to be at least one implementation where expanding the
DEFUN macro causes all constants in the body of the function to be
copied.
Cost to implementors:
Proposal NO-COPYING would involve a significant cost in those
implementations where constants are now copied or coalesced by EVAL
and COMPILE. Some implementations would also require substantial
changes to support proposal COPYING-ALLOWED-BUT-NO-CONSTRAINTS. The
aspect that is likely to cause the most problems is that, in some
implementations, the garbage collector assumes that constants
referenced in compiled code have been copied to read-only storage and
do not need to be scanned or relocated.
Proposal SAME-AS-COMPILE-FILE has no adoption cost above what is
required to support issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION.
Cost to users:
Proposals COPYING-ALLOWED-BUT-NO-CONSTRAINTS and SAME-AS-COMPILE-FILE
may break some existing programs that assume constants in code
processed by EVAL or COMPILE are always EQL to the corresponding
objects in the source code. Proposal SAME-AS-COMPILE-FILE may also
break existing programs that depend on referencing "undumpable"
constants in code processed by EVAL or COMPILE. In both cases,
however, the behavior is already nonportable. Both proposals would
permit implementations in which these programs now work to continue to
provide their existing behavior.
Benefits:
The semantics of QUOTE are clarified.
Discussion:
This issue subsumes issue QUOTE-MAY-COPY, which caused a very lengthy
debate on the cl-compiler mailing list.
This issue relates to conformance requirements. Accepting either of
proposals NO-COPYING or COPYING-ALLOWED-BUT-NO-CONSTRAINTS would mean
that not all conforming programs could be compiled with COMPILE-FILE.
Some people may find this disturbing, particularly since one of the
goals of Common Lisp has been to try to eliminate differences in
semantics between compiled and interpreted code.
Loosemore supports proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE,
since it requires essentially no conversion cost for implementors and
does not break any user programs that are not already nonportable.
JonL White says:
Since we have already passed the proposal that permits constants to
be "read-only" -- it is an error to modify them -- and have already
passed the proposal that allows access to updateable structures --
LOAD-TIME-EVAL -- then there is no excuse for being overly concerned
with the storage address of quoted data. People who have mistakenly
used structured constants as updatable data should convert over to
either LOAD-TIME-EVAL or DEFPARAMETER.
Kent Pitman says:
The problem is that a lot of copying advocates have been going around
trying to use "the need for copying" as leverage for restricting
the set of things which I may quote. My view is that it is my write [sic]
to quote whatever I want, and it's up to the person who thinks they
can do something fun with copying to not get themselves in deeper than
they can handle.
Jeff Dalton says:
I would agree [with Pitman's remarks] too. My only quibble is that
it's not just "the need for copying" that's used a lever.
"Consistency with file compilation" is also being used as a lever.
∂13-Mar-89 0929 X3J13-mailer issue SAFE-CODE, version 1
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 09:29:10 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA21179; Mon, 13 Mar 89 10:26:59 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02193; Mon, 13 Mar 89 10:26:56 -0700
Date: Mon, 13 Mar 89 10:26:56 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131726.AA02193@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue SAFE-CODE, version 1
Issue: SAFE-CODE
Forum: Compiler
References: OPTIMIZE declaration (p160),
Issue ERROR-TERMINOLOGY
Category: CLARIFICATION/CHANGE
Edit history: 07-Mar-89, Version 1 by Pitman
Status: Ready for release
Problem Description:
The new error terminology refers to ``safe code'' in the definition
of the term and CLtL refers to
individual meanings of OPTIMIZE qualities, but there is no standardized
way of relating the two concepts.
Proposal (SAFE-CODE:SAFETY-3):
Define that, formally, the term ``safe code'' is code refers to any
code in which the OPTIMIZE quality for SAFETY has a value of 3.
Implementors might wish to consider treating other situations as safe
as well, but in making that decision both the relative values of other
OPTIMIZE qualities and the idiosyncratic properties of the particular
implementation should also be taken into account.
Examples:
1. The body of the following is safe...
a. (LOCALLY (DECLARE (OPTIMIZE (SAFETY 3))) . body)
b. (LOCALLY (DECLARE (OPTIMIZE SAFETY )) . body)
2. The body in each of the following is unsafe. They might
or might not be treated as safe, possibly depending
on the values of other qualities and specifics of the
implementation.
a. (LOCALLY (DECLARE (OPTIMIZE (SAFETY 0))) . body)
b. (LOCALLY (DECLARE (OPTIMIZE (SAFETY 1))) . body)
c. (LOCALLY (DECLARE (OPTIMIZE (SAFETY 2))) . body)
Rationale:
Programmers will probably intuitively expect that the term
``highest safety'' refers to giving the SAFETY quality its
highest safety.
Current Practice:
Implementors ...
Symbolics Genera does error checking always, and ignores OPTIMIZE
declarations.
Symbolics Cloe heeds OPTIMIZE declarations, but effectively makes
`judgment calls' in every case because there is no clear guidance
on how to interpret them.
Programmers ...
Many programmers write (DECLARE (SPEED 0) (SAFETY 3)) even when all
they really want to control is SAFETY because they are afraid that
unless they explicitly sacrifice speed, the compiler will ignore
their plea for error checking.
Cost to Implementors:
Some implementations might require a lot of nitpicky little changes.
Cost to Users:
Technically none. No portable code can really rely on much of any
reliable effect out of any of the OPTIMIZE qualities. However, some
users may rely on implementation-specific features of implementations,
and if those implementations are forced to change, non-portable user
code might break in some ways.
Cost of Non-Adoption:
The meaning of ``safe code'' will not be clearly defined.
Benefits:
Programmers will be able to say what they mean. They can stop
superstitiously putting (SPEED 0) next to (SAFETY 3) just to
assure they get safe code.
Aesthetics:
Improved. This will make the English align well with the code.
Discussion:
It is very important that we reach consensus in some form on this issue.
Pitman supports SAFE-CODE:SAFETY-3.
∂13-Mar-89 1014 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 10:14:33 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 13:09:40 EST
Date: Mon, 13 Mar 89 13:10 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: UNSOLICITED-MESSAGES
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: <890313115113.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890313181059.0.BARMAR@OCCAM.THINK.COM>
Date: Mon, 13 Mar 89 11:51 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Date: Mon, 13 Mar 89 11:35 EST
From: Barry Margolin <barmar@Think.COM>
Do progress notes in the wholine count as output? If not, why not? ...
No. They are passive. The function in question does not output to the
wholine. Rather, it arranges information such that a foreign process
can access it and display it. For example, if 500 calls to LOAD are done
in three second, you don't always get 500 progress messages. That is
because the output is done by the foreign process doing the polling and
not the process which is running the CL code. I think this distinction
is important. Indeed, if the running process could block, signal an
error, etc. due to problems in I/O then it would not be a good idea.
So, the acceptability of progress notes has nothing to do with the
stream they are displayed on, only the fact that they are displayed by a
background process? This implies that a single-tasking machine that
displayed progress notes synchronously would therefore be unacceptable.
I find this distinction extremely arbitrary, since it is based only on
the implementation, not the program-visible effects.
I like these things, but I think it will be difficult to express this
distinction in general enough terms in the standard.
I don't think it's that difficult.
We'll have to come up with a general definition of passive output versus
active output. And we'll still have to make sure that passive output
isn't allowed to go to *STANDARD-OUPTUT*.
Why is this problem unique to Lisp? Is there any wording in the C
standard that explicitly prohibits malloc() from causing output? I
doubt it, yet I don't think they find this disturbing.
Maybe it's because C people have traditionally been willing to settle
for less. :-) Seriously, I think it's a clear hole in their standard.
People would probably flame if things that weren't documented as doing
I/O were to suddenly start doing it.
Actually, I think the difference is that Common Lisp includes some
operations that are not traditionally included in runtime libraries,
COMPILE, COMPILE-FILE, and LOAD being the most notable ones. No
Lisp implementor would even think of having CONS or EQ produce output,
just as the C standard doesn't need to say that malloc() is silent.
Perhaps this means that since we have such unusual runtime facilities,
we can't rely on common sense as other languages do. I would be willing
to support a blanket statement that said that no output may be produced
by functions other than that specified in the standard or due to the
signalling of conditions detected by the function.
Would this prevent an implementation from having a *DEBUG-CONS* variable
that turns on debugging output by CONS?
barmar
∂13-Mar-89 1046 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 10:46:36 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555842; Mon 13-Mar-89 13:43:40 EST
Date: Mon, 13 Mar 89 13:43 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNSOLICITED-MESSAGES
To: x3j13@sail.stanford.edu
cc: barmar@Think.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: <890313115113.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890313134321.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
[Further discussion on this topic will take place on CL-Editorial.]
∂13-Mar-89 1450 X3J13-mailer **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:50:22 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA07805; Mon, 13 Mar 89 15:48:10 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02496; Mon, 13 Mar 89 15:48:08 -0700
Date: Mon, 13 Mar 89 15:48:08 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132248.AA02496@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
This issue is still under discussion. There has been a lot of talk
about how this relates to the creation of meta-objects at compile
time, but the only proposals that have been made so far are the two
included here.
Forum: Compiler
Issue: CLOS-MACRO-COMPILATION
References: CLOS chapters 1 & 2 (88-002R)
CLOS chapter 3 (89-003)
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION
Edit History: V1, 10 Mar 1989, Sandra Loosemore
V2, 13 Mar 1989, Sandra Loosemore
Status: **DRAFT**
Problem Description:
Do the CLOS defining macros (DEFCLASS, DEFMETHOD, DEFGENERIC, and
DEFINE-METHOD-COMBINATION) have compile-time side-effects similar
to those for DEFSTRUCT or DEFMACRO?
A part of the problem is that we do not currently have a full
understanding of all the issues involved. In particular, work on
defining the CLOS meta-object protocol is still in progress. The goal
of this proposal is to say enough about the behavior of these macros
in the standard so that users can use them portably in compiled code,
but to leave as much of the behavior as possible unspecified to avoid
placing undue restrictions on the meta-object protocol.
There are two proposals, MINIMAL and NOT-SO-MINIMAL.
Proposal CLOS-MACRO-COMPILATION:MINIMAL:
State that top-level calls to the CLOS defining macros have the
following compile-time side-effects. Any other compile-time behavior
is explicitly left unspecified.
DEFCLASS:
* The class name becomes a type specifier which may appear in
subsequent type declarations.
* The class name can be used to name a superclass in a subsequent
DEFCLASS.
* The class name can be used as a specializer in a subsequent
DEFMETHOD.
DEFGENERIC:
* The generic function can be referenced in a subsequent DEFMETHOD.
* The generic function is not callable at compile-time.
DEFMETHOD:
* The method is not callable at compile-time. If there is a generic
function with the same name at compile-time, compiling a DEFMETHOD
will not add the method to that generic function. The compiler may
perform tests for lambda-list congruence only between the DEFGENERICs
and DEFMETHODs for a given generic function name that appear within
the file being compiled, and not against a generic function of the
same name which exists in the compile-time environment.
DEFINE-METHOD-COMBINATION:
* The method combination can be used in a subsequent DEFGENERIC. If it
is referenced, the body of a long form of method combination must be
evaluable at compile-time.
Rationale:
The compile-time behavior of DEFCLASS is similar to DEFSTRUCT or
DEFTYPE.
DEFGENERIC and DEFMETHOD are similar to DEFUN, which doesn't add the
function definition to the compile-time environment. Since generic
functions may be freely redefined between compile and run time (just
like any other function), a method may end up "belonging" to a
different generic function at load time than at compile time.
Some implementations compose effective methods at compile time, which
requires evaluating the body of the DEFINE-METHOD-COMBINATION at
compile time.
Proposal CLOS-MACRO-COMPILATION:NOT-SO-MINIMAL:
This is the same as proposal MINIMAL, except under DEFCLASS add:
* The class may be instantiated at compile-time. Provided the
appropriate methods are also defined at compile-time, this implies:
- The class can be used as the :METACLASS option of a later DEFCLASS.
- It can be used as the :GENERIC-FUNCTION-CLASS or :METHOD-CLASS option
of a DEFGENERIC, GENERIC-FUNCTION, GENERIC-FLET, or GENERIC-LABELS.
Rationale:
Being able to instantiate a class at compile-time is somewhat more
convenient for users.
Current Practice:
The items listed under DEFCLASS in proposal MINIMAL are fairly standard
programming style.
Flavors does not support compile-time instantiation of classes. It
does not make method combinations available at compile-time either, but
Moon considers that to be a bad design choice.
Cost to implementors:
Unknown.
Cost to users:
Unknown, but probably fairly small.
Note that for proposal NOT-SO-MINIMAL, users still have to ensure that
any methods on the class which may be invoked at compile-time are
fully defined. This includes the INITIALIZE-INSTANCE and
SHARED-INITIALIZE methods that are invoked by MAKE-INSTANCE.
Wrapping an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the appropriate
definitions will make sure they are fully defined at compile-time.
Alternatively, the definitions could be placed in a separate file,
which is loaded before compiling the file that depends on those
definitions.
Benefits:
Programmers can rely on programs that use the CLOS defining macros
being able to compile correctly in all implementations, without having
to wrap explicit EVAL-WHENs around every macro call.
Discussion:
This writeup is based on discussions between Moon, Gray, and
Loosemore, who are mostly in agreement on the things presented in
proposal MINIMAL. We have purposely avoided saying anything about
whether meta-objects representing the classes, methods, etc. get
created at compile-time, or whether such meta-objects are fully or
partially defined. The basic questions addressed by this issue are
what kinds of things can be defined and then used during compilation
of the same file that defines them, and what restrictions might apply.
These proposals are not completely compatible with the meta-object
protocol document (89-003). Gregor Kiczales says:
No one believes that what is written in draft 10 of the MOP is valid.
Sandra Loosemore says:
Although I admit I don't understand all of the issues involved with
the meta-object protocol, I prefer proposal MINIMAL over
NOT-SO-MINIMAL. I don't think leaving the issue of whether or not
classes can be instantiated at compile-time unspecified places an
undue burden on users, and it does leave more freedom for the
meta-object protocol to decide what the right behavior really is.
Dick Gabriel notes:
The question I have about the process going on with respect to the
CLOS-MACRO-COMPILATION issue is whether the fine-grained behavior of
CLOS under various compilation/evaluation situations is being
over-specified.
At this stage of the game I worry that we might go a little too far in
one direction in specification when we are actually engaged in design
work. This isn't intended to be a criticism of any committees, but I
would feel a lot more comfortable with a conservative specification
that defined well-formed programs being loaded or compiled in fresh
Common Lisps with a pretty simple eval-when model that is easier to
specify and which makes it easy for all but the hairiest
compilation-environment-frobbing programs to be written.
∂13-Mar-89 1452 X3J13-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:52:29 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA07899; Mon, 13 Mar 89 15:50:10 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02499; Mon, 13 Mar 89 15:50:07 -0700
Date: Mon, 13 Mar 89 15:50:07 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132250.AA02499@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Forum: Compiler
Issue: COMPILE-ENVIRONMENT-CONSISTENCY
References: CLtL p. 68-69, 143, 321
RAM's "Compiler Cleanup Proposal #3"
Category: CLARIFICATION
Edit History: V1, 2 Sep 1988, Sandra Loosemore (initial draft)
V2, 9 Sep 1988, Sandra Loosemore (incorporate suggestions)
V3, 26 Oct 1988, Sandra Loosemore (add suggestion from Benson)
V4, 08 Mar 1989, Sandra Loosemore (wording changes)
Problem Description:
CLtL does not clearly specify what aspects of the compiletime
environment the compiler (or other preprocessor) may "wire in" to code
being compiled. At what time (compiletime or runtime) are certain
kinds of definitions "captured"? What happens if these definitions
are not consistent at both compile and run times?
Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY:
The process of compilation causes certain kinds of information present
in the compiletime environment to be captured and incorporated into
the resulting compiled code. Other kinds of information may not be
captured until the compiled code is actually run.
Specifically:
(1) The following information *must* be present in the compiletime
environment for the program to be compiled correctly. This
information need not also be present in the runtime environment.
(a) In conforming code, macros referenced in the code being compiled
must have been previously defined in the compiletime environment.
The compiler must treat any form that is a list beginning with
a symbol that does not name a macro or special form as a function
call. (This implies that SETF methods must also be available at
compiletime.)
(b) In conforming code, variables that are intended to be bound
specially must be declared SPECIAL in the compiletime environment
before any bindings of that variable are processed by the compiler.
The compiler must treat any binding of an undeclared variable as a
lexical binding.
(2) The compiler *may* incorporate the following kinds of information
into the code it produces, if the information is present in the
compiletime environment and is referenced within the code being
compiled. Except where some other behavior is explicitly stated, when
the compiletime and runtime definitions are different, it is
unspecified which will prevail within the compiled code. In all
cases, the absence of the information at compiletime is not an error,
but its presence may enable the compiler to generate more efficient
code.
(a) The compiler may assume that functions that are defined and
declared INLINE in the compiletime environment will retain the
same definitions at runtime.
(b) The compiler may assume that, within a named function, a
recursive call to a function of the same name refers to the
same function, unless that function has been declared NOTINLINE.
(c) COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at runtime.
(d) The compiler may assume that the signature (or "contract") of
all built-in Common Lisp functions will not change. In addition,
the compiler may treat all built-in Common Lisp functions as if
they had been proclaimed INLINE.
(e) The compiler may assume that the signature (or "contract") of
functions with FTYPE information available will not change. (See
issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS.)
(f) The compiler may "wire in" the values of symbolic constants
that have been defined with DEFCONSTANT in the compiletime
environment.
(g) The compiler can assume that type definitions made with DEFTYPE
or DEFSTRUCT in the compiletime environment will retain the same
definition in the runtime environment. It may also assume that
a class defined by DEFCLASS in the compiletime environment will
be defined in the runtime environment in such a way as to have
the same superclasses and metaclass. This implies that
subtype/supertype relationships of type specifiers will not
change between compiletime and runtime. (Note that it is not
an error for an unknown type to appear in a declaration at
compiletime, although it is reasonable for the compiler to
emit a warning in such a case.)
(h) The compiler may assume that if type declarations are present
in the compiletime environment, the corresponding variables and
functions present in the runtime environment will actually be of
those types; otherwise, the runtime behavior of the program is
undefined.
(3) The compiler *must not* make any additional assumptions about
consistency between the compiletime and runtime environments. In
particular:
(a) The compiler may not assume that functions that are defined
in the compiletime environment will retain the either the
same definition or the same signature at runtime, except
in situations (2a) through (2e) above. It is, however,
permissible for the compiler to emit warning messages when
compiling calls to functions that are defined in the compiletime
environment, but where the wrong number or type of arguments
are supplied.
(b) The compiler may not signal an error if it sees a call to a
function that is not defined at compiletime, since that function
may be provided at runtime. Again, it is permissible for the
compiler to emit a warning in these situations.
Rationale:
This proposal generally reflects current practice.
Current Practice:
There don't seem to be any compilers around that do not implement the
provisions of item (1).
For item (2), most compilers (including Lucid) optimize self-recursive
calls by default. Most compilers also opencode data structure
accessors (such as CAR) at some level of optimization, and some code
much more complicated built-in functions inline as well. VaxLisp, for
example, normally compiles MEMBER inline. The Lucid compiler makes
use of type declarations to perform generic-to-specific
transformations on many arithmetic and sequence functions, which is
also a form of inlining. KCL performs block compilation by default,
and Lucid does so under certain conditions.
Cost to implementors:
Unknown, but probably minor.
Cost to users:
Since most implementations appear to be largely in conformance with the
proposal, users should notice little difference.
Benefits:
The presence of a definite specification of what may happen when will
help users structure their programs so they will compile correctly in
all Common Lisp implementations.
Discussion:
Most of the discussion on this issue has been centered on the
terminology describing error situations for item (2). In most cases
where there is an inconsistency between compile-time and run-time, the
results will be unpredictable but harmless. The major exception is
violation of type declarations, which is a "crash-and-burn" error in
many implementations.
There has also been some concern raised that item (3) would prohibit
such things as a cross-compiler that produces standalone programs in
an environment that disallows redefinition of functions. The intent
of this proposal is not to prohibit a compiler from having a magic
switch that imposes additional restrictions on the programs it
compiles, but such a compiler would not be a compiler for Common Lisp.
Several people have expressed reservations about items 2b and 2c, saying
that self-tail-recursion optimization and block compilation should not
be the default behavior of the compiler. Gail Zacharias responds:
This item [2c] has nothing to do with whether anybody does it by
default. The question is whether an end user can take a Common Lisp
program whose internals he's not familiar with, block-compile it, and
be guaranteed that it will continue to function correctly. This item
says that yes, a correct CL program must explicitly indicate what
functions in the source it will redefine at runtime. I don't think
this places such a great burden on the programmer. Without this
provision, only somebody intimately familiar with a program could know
whether it can be safely block-compiled, making block-compilation
useless in the context of portable CL programs.
This thing about "block compilation shouldn't be the default" seems to
come up every time this item is discussed. That's an environment
question and is not addressed by the proposal. The proposal simply
says that block compilation should be legal.
∂13-Mar-89 1514 X3J13-mailer issue COMPILE-FILE-SYMBOL-HANDLING, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:14:36 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA08718; Mon, 13 Mar 89 16:12:23 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02542; Mon, 13 Mar 89 16:12:19 -0700
Date: Mon, 13 Mar 89 16:12:19 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132312.AA02542@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 2
Forum: Compiler
Issue: COMPILE-FILE-SYMBOL-HANDLING
References: CLtL p. 182
Issue IN-PACKAGE-FUNCTIONALITY
Issue CONSTANT-COMPILABLE-TYPES
Issue DEFPACKAGE (passed)
Category: CHANGE/CLARIFICATION
Edit History: V1, 01 Feb 1989, Sandra Loosemore
V2, 12 Mar 1989, Sandra Loosemore (discussion, error terms)
Status: Ready for release
Problem Description:
It is not clear how COMPILE-FILE is supposed to specify to LOAD how
symbols in the compiled file should be interned. In particular, what
happens if the value of *PACKAGE* is different at load-time than it
was at compile-time, or if any of the packages referenced in the file
are defined differently?
There are three proposals: CURRENT-PACKAGE, HOME-PACKAGE, and
REQUIRE-CONSISTENCY.
Proposal COMPILE-FILE-SYMBOL-HANDLING:CURRENT-PACKAGE:
When a compiled file is loaded, the interned symbols it references
are found by the following procedure. The rules are applied in the
order listed and only the first applicable rule has any effect.
(1) Any symbol accessible at compile time in the package that is the
value of *PACKAGE* is found by calling INTERN at load time with one
argument, the name of the symbol.
(2) A keyword symbol is found by finding or creating a keyword symbol
with the same name.
(3) A symbol that at compile time is an external symbol of its home
package is found at load time by finding the package with the same
name as the compile-time home package, and then finding an exported
symbol of that package with the same name as the compile-time symbol.
If no such package exists, no such symbol exists, or the symbol is not
exported, an error is signalled.
(4) Any other symbol is found by calling INTERN at load time with two
arguments, the name of the symbol and the package with the same name
as the compile-time symbol's home package. If no such package exists,
an error is signalled.
The goal of this procedure is for each symbol reference to be
resolved to the same symbol when a compiled file is loaded as when
the source file is loaded directly with LOAD. It is possible to
create package structures that make that impossible; for example, it
is possible for a symbol to be inaccessible from its own home
package. A conforming program cannot depend on any symbol
resolution behavior that is not provided by the above four rules.
If any top level form in a compiled file changes the value of
*PACKAGE*, other than a SELECT-PACKAGE appearing as the first
top level form in the file, the package in which the loader will
place the constant symbols referenced in the file is unspecified.
Rationale:
Proposal CURRENT-PACKAGE makes COMPILE-FILE/LOAD follow the same
rules as PRINT/READ. For any symbol not written with a package
prefix in the source file (which should be the great majority of
them), CURRENT-PACKAGE will make loading the compiled file get the
same symbols as loading the source file.
The reason for the rule about changing the value of *PACKAGE* is that
many loaders cache the interning of symbols; if the same symbol
appears multiple times in the source file, its name may only be
looked up once at load time. Since not all loaders are required to
work this way, changing *PACKAGE* in mid-file is not allowed,
because the effect on later occurrrences of a symbol would be
implementation-dependent.
Proposal COMPILE-FILE-SYMBOL-HANDLING:HOME-PACKAGE:
When a compiled file is loaded, the interned symbols it references are
found by calling INTERN at load time with two arguments, the name of
the symbol and the package with the same name as the compile-time
symbol's home package. If no such package exists, an error is
signalled.
The goal of this procedure is for each symbol reference to be resolved
to the same symbol when a compiled file is loaded as when the source
file was processed by COMPILE-FILE. A conforming program cannot
depend on any symbol resolution behavior that is not provided by the
above rule.
If any top level form in a compiled file changes the value of
*PACKAGE* when the file is loaded interpretively but not during
compile-time processing by COMPILE-FILE, the package in which the
loader will place the constant symbols referenced in the file is
unspecified.
Rationale:
The behavior specified in this proposal is simple and easy to
understand (there is only one rule to remember instead of four).
It does not require any restrictions on where top-level
SELECT-PACKAGE forms may appear in the file. It allows a compiled
file that does not include an explicit SELECT-PACKAGE to be loaded
successfully no matter what the load-time value of *PACKAGE* is,
as long as the compile-time value of *PACKAGE* was the "right"
package.
Proposal COMPILE-FILE-SYMBOL-HANDLING:REQUIRE-CONSISTENCY:
In order to guarantee that compiled files can be loaded correctly,
users must ensure that the packages referenced in the file are defined
consistently at compile and load time. Conforming Common Lisp programs
must satisfy the following requirements:
(1) The value of *PACKAGE* when the contents of the file are compiled
by COMPILE-FILE must be the same as the value of *PACKAGE* when
the file is loaded. In particular:
(a) If any top level form in a compiled file changes the value
of *PACKAGE*, other than a SELECT-PACKAGE appearing as the first
top-level form in the file, the package in which the loader
will place the constant symbols referenced in the file is
unspecified.
(b) If the first top-level form in the file is not a call to
SELECT-PACKAGE, then the value of *PACKAGE* at the time LOAD is
called must be a package with the same name as the package that
was the value of *PACKAGE* at the time COMPILE-FILE was called.
(2) For all symbols that were accessible in *PACKAGE* at compile
time but whose home package was another package, at load time there
must be a symbol with the same name that is accessible in both the
load-time *PACKAGE* and in the package with the same name as the
compile-time home package.
(3) For all symbols in the compiled file that were external symbols in
their home package at compile time, there must be a symbol with the
same name that is an external symbol in the package with the same name
at load time.
If any of these conditions do not hold, the package in which LOAD looks
for the affected symbols is unspecified. Implementations are permitted
to signal an error or otherwise define this behavior.
Otherwise, when a compiled file is loaded, the interned symbols it
references are found by calling INTERN at load time with two
arguments, the name of the symbol and the package with the same name
as the compile-time symbol's home package. If no such package exists,
an error is signalled.
Rationale:
Any program that behaves differently under the other two proposals
is already nonportable. This proposal is merely an explicit
statement of the status quo, namely that users cannot depend on
any particular behavior if the package environment at load time is
inconsistent with what existed at compile time.
Current Practice:
PSL/PCLS implements something very similar to proposal HOME-PACKAGE,
as does A-Lisp. Utah Common Lisp implements something like proposal
CURRENT-PACKAGE, but the chief compiler hacker says he thinks that
proposal HOME-PACKAGE actually makes more sense, and agrees that any
program that behaves differently under the two proposals is broken.
The TI Explorer currently implements proposal HOME-PACKAGE, after
trying it both ways.
KCL implements something like HOME-PACKAGE (symbols in the compiled
file are explicitly qualified with the name of their home package),
except that it differentiates between internal and external symbols.
Lucid Lisp appears to implement something like proposal CURRENT-PACKAGE.
Symbolics Genera implements CURRENT-PACKAGE. Symbolics Cloe probably
does also.
Coral also implements something like proposal CURRENT-PACKAGE.
Cost to implementors:
Proposals HOME-PACKAGE and CURRENT-PACKAGE would be incompatible
changes for implementations that currently do things the other way.
It would probably be easier to convert to HOME-PACKAGE than
CURRENT-PACKAGE, since it is less complicated.
Proposal REQUIRE-CONSISTENCY is intended to be compatible with either
of the other two proposals, but it may not be entirely compatible with
the details of current implementations.
Cost to users:
Proposal HOME-PACKAGE places the fewest restrictions on user programs.
Proposal CURRENT-PACKAGE places a restriction on where and how the value
of *PACKAGE* may be changed within the file.
Proposal REQUIRE-CONSISTENCY places even more restrictions on user
programs.
Most of these restrictions are probably already necessary in portable
programs. However, some nonportable programs that depend on the "other"
model may be broken by proposals HOME-PACKAGE or CURRENT-PACKAGE.
For a discussion of how these proposals treat nonportable or erroneous
programs, see the "Analysis" section below.
Benefits:
COMPILE-FILE's treatment of symbols is made explicit in the standard.
Analysis:
Proposals CURRENT-PACKAGE and HOME-PACKAGE present two different
models of how this problem might be solved. Essentially, proposal
CURRENT-PACKAGE uses the same rules as PRINT/READ in deciding when to
qualify symbols with a package name and where to find unqualified
symbols. Proposal HOME-PACKAGE requires -all- symbols written to the
compiled file to be qualified with an explicit package, and the loader
simply INTERNs the symbol names in that package.
These two proposals differ in the following situations. Proposal
REQUIRE-CONSISTENCY, in effect, says that valid programs do not cause
any of these situations to occur, and the behavior in such cases is
unspecified (allowing both models to be used as valid implementation
techniques).
(1) The situation where the file does not contain a SELECT-PACKAGE
and where the compile-time value of *PACKAGE* is a package with a
different name than the load-time value of *PACKAGE*.
Proposal CURRENT-PACKAGE would intern the names of symbols that
were accessible in *PACKAGE* at compile time in *PACKAGE* at load time.
Proposal HOME-PACKAGE would intern the names of symbols that
were accessible in *PACKAGE* at compile time in the package with
the same name as their compile-time home package.
In general, programs must be compiled in the "right" package, so
that the compiler can find and apply the correct macro expansions,
type definitions, and so on; see issue COMPILE-ENVIRONMENT-CONSISTENCY.
As a result of macroexpansion or other transformations applied by
the compiler, the compiled file may contain symbol references that
were not present in the source file. Proposal CURRENT-PACKAGE may
cause problems because these references may be resolved to be
symbols other than the ones that were intended. Since proposal
HOME-PACKAGE remembers the home package of all symbols, it is much
more likely to find the correct symbols at load time.
(2) The situation where *PACKAGE* is altered by a top-level form
that is not a SELECT-PACKAGE which is the first top-level form in
the file.
Proposal CURRENT-PACKAGE says this is illegal. This is because
of the difficulty in deciding what the "current package" is, if it
is allowed to change throughout the file.
Proposal HOME-PACKAGE says this is OK, as long as *PACKAGE* is
altered in the same way at compile time as when the file is loaded
interpretively. This is possible because the behavior this
proposal specifies does not depend on what the value of *PACKAGE*
is once symbols in the source file have been read by COMPILE-FILE.
Some people argue that allowing *PACKAGE* to be switched in
mid-file is a bad idea anyway; it is not really necessary and it
implies a restriction on COMPILE-FILE to read forms from the file
one at a time, processing each form before the next call to READ.
Others argue that restricting SELECT-PACKAGE to be the first
top-level form is an artificial contrivance. The compile-time
behavior of SELECT-PACKAGE is well-defined no matter where it
appears in the file. There is also a problem defining what "the
first top-level form" really means. Finally, this model requires
all package definitions to be made externally to the file, which
may be inconvenient for smaller programs that now contain the
package definition and package contents all in one file.
(3) The situation where there is a symbol accessible in the
compile-time value of *PACKAGE* but with another home package, and
where at load time there is not a symbol with the same name that
is accessible in both packages. This situation might occur, for
example, if at compile time there is a symbol that is external in
its home package and that package is used by *PACKAGE*, but where
there is no such external symbol in that package at load time, or
the load-time *PACKAGE* does not use the other package.
Proposal CURRENT-PACKAGE would find or create a symbol accessible
in *PACKAGE*.
Proposal HOME-PACKAGE would find or create a symbol accessible in
a package with the same name as the symbol's compile-time home
package.
Some people feel that the behavior of proposal CURRENT-PACKAGE is
more intuitive in this situation, and that it is more forgiving of
differences between the compile-time and load-time package
structures. Others feel that the behavior of HOME-PACKAGE is more
intuitive, and that if there have been significant changes to the
package structures, it is probably an indication that the file
needs to be recompiled anyway, since the compiler might have
picked up macro definitions and the like from the wrong package.
(4) The situation where a symbol is external in its home package
and where there is no such external symbol in that package at load
time.
Proposal CURRENT-PACKAGE would quietly find or create the symbol
in *PACKAGE* if the symbol were accessible in *PACKAGE* at compile
time. Otherwise, it will signal an error.
Proposal HOME-PACKAGE would always just quietly find or create the
symbol as internal in its home package.
Not complaining when a symbol that is supposed to be external
isn't can be seen as a violation of modularity. However, it seems
like this argument should apply equally to symbols whose home
package is *PACKAGE* as symbols whose home package is somewhere
else.
Discussion:
Loosemore is opposed to proposal CURRENT-PACKAGE, but would be
less opposed to it if it contained an explicit statement that
*PACKAGE* must be a package with the same name at load time as at
compile time. She thinks proposal HOME-PACKAGE is the best of the
options presented here.
Moon is opposed to proposal HOME-PACKAGE, but would be less
opposed to it if it required an error to be signalled when a
symbol that was external at compile time is not external at load
time. He thinks proposal CURRENT-PACKAGE is the best of the options
presented here.
John Kolts, who did the implementation on the TI Explorer, recalls:
My primary motivation was compile/load consistency. I thought it was
important that during loading all symbol references should resolve to
the same symbol as they would have during the compilation. If, for
instance, the packages used by *package* were different at compile
time than at load time, my approach would still intern the accessible
symbols in the "right" package during loading. [...] Of course, such
an approach means that loading the [compiled file] could give results
incompatible with loading the LISP file directly, but I felt that if
behavior consistent with some altered package structure was desired,
the file should be recompiled, a relatively small price to pay for the
benefit of this consistency.
A related consideration was that remembering the home package seemed to
be important for proper macro expansion in certain cases.
What was apparent was that there were several defensible approaches,
none of which was obviously the absolutely right way to handle certain
pathological situations. Making the expected behavior explicit in a
standard is a good idea.
David Gray says:
There really shouldn't be anything wrong about using SELECT-PACKAGE
multiple times within a file as long as it is used at top level so
that the compiler knows that the current package is being changed.
Cris Perdue says:
[Proposal HOME-PACKAGE] doesn't ensure that the home package remains
the same across compilation and loading, which I consider the key
consideration. How about this statement instead?
"When a file is compiled, the symbol name is recorded together
with the home package name and an indication of whether the
symbol is external in its home package. At load time the
symbol is effectively looked up with:
(find-symbol string (find-package pkg-name))
If the symbol is noted as external, it must be found at load
time as :external. If it is noted as internal, it must either
be present in the package or not found at all. If it is not found
at all, it is created as if by:
(intern string (find-package pkg-name))
If the package system is not in a suitable state, an error is
signalled."
This is what I consider "the right thing".
JonL White says:
I don't believe we have anything to gain at this point in trying to
standardize the faslout package-qualification algorithm; this is
notwithstanding that standardizing PRINT output, as an interchange
format, is an absolute requirement [even though READ-of-PRINT will
likely be even more information losing than loading in a compiled
file!]
∂13-Mar-89 1517 X3J13-mailer issue COMPILER-LET-CONFUSION, version 7
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:16:50 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA08737; Mon, 13 Mar 89 16:14:30 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02546; Mon, 13 Mar 89 16:14:26 -0700
Date: Mon, 13 Mar 89 16:14:26 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132314.AA02546@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILER-LET-CONFUSION, version 7
Issue: COMPILER-LET-CONFUSION
Forum: Compiler
References: CLtL p. 112
Category: CHANGE
Edit History: V1, 27 Sep 1988, Sandra Loosemore (initial version)
V2, 04 Oct 1988, Sandra Loosemore (add another example)
V3, 31 Oct 1988, Sandra Loosemore (only proposal ELIMINATE)
V4, 08 Jan 1989, Kent M. Pitman (new alternative)
V5, 09 Jan 1989, Sandra Loosemore (discussion)
V6, 08 Mar 1989, Sandra Loosemore (general updating)
V7, 13 Mar 1989, Sandra Loosemore (fix bug from V6)
Problem Description:
The description of the COMPILER-LET special form in CLtL is confusing
to many people. There are no examples provided to make it clear how it
is supposed to be used. The only description which is offered is overly
concrete, which has led to confusion about the intent of COMPILER-LET,
and about its implementability.
The intent of COMPILER-LET was to permit information to be communicated
between macros by use of dynamic variables at macroexpansion time.
It was not necessary to the intended uses of COMPILER-LET that such
variables ever be bound at execution time.
Unfortunately, probably because some implementations did not primitively
support COMPILER-LET at the time CLtL was written, an exception was
permitted to make COMPILER-LET `more or less work' in interpreters:
the COMPILER-LET variables were permitted to be bound at execution time.
The problem was further compounded by the fact that CLtL presented this
exception as part of COMPILER-LET's contract rather than as an
implementation note, and by the fact that no examples of actually using
COMPILER-LET correctly are provided.
One particular case where problems have resulted is a situation like
(compiler-let ((*v* 1))
#'(lambda () (m)))
where M is a macro that refers to *V*. In some implementations, M is
not macroexpanded until the dynamic extent of the *V* binding has
ended.
Subtle bugs can be introduced because of the different handling of the
variable bindings in the interpreter and the compiler. In compiled
code, the bindings are only lexically visible during the expansion of
macros at compile time, while in interpreted code the bindings have
dynamic scope and may also be seen during ordinary evaluation if
evaluation and macroexpansion happen "in parallel".
Further compatibility problems can result from the value forms being
evaluated in a null lexical environment in the compiler and the ordinary
lexical environment in the interpreter.
Background and Analysis:
It should be clear up front that COMPILER-LET is not computationally
essential. Most (if not all) uses of it can be rewritten using MACROLET
or SYMBOL-MACROLET.
A typical use of COMPILER-LET might be:
(defvar *local-type-declarations* '())
(defmacro local-type-declare (declarations &body forms)
`(compiler-let ((*local-type-declarations*
(append ',declarations *local-type-declarations*)))
,@forms))
(defmacro typed-var (var)
(let ((type (assoc var *local-type-declarations*)))
(if type `(the ,(cadr type) ,var) var)))
(defun f (x y)
(local-type-declare ((x fixnum) (y float))
(+ (typed-var x) (typed-var y))))
The same thing could be accomplished using MACROLET:
(defmacro local-type-declare (declarations &body forms)
(local-type-declare-aux declarations forms))
(defmacro typed-var (var) var)
(eval-when (eval compile load)
(defun local-type-declare-aux (declarations forms)
`(macrolet ((typed-var (var)
(let ((type (assoc var ',declarations)))
(if type `(the ,(cadr type) ,var) var)))
(local-type-declare (new-declarations &body new-forms)
(local-type-declare-aux
(append new-declarations ',declarations)
new-forms)))
,@forms)))
A further alternative would be to use SYMBOL-MACROLET (this particular
implementation assumes that issue DEFINING-MACROS-NON-TOP-LEVEL passes):
(let ((temp (gensym)))
(defmacro local-type-declare (declarations &body forms &environment env)
`(symbol-macrolet ((,temp ',(append declarations
(symbol-macro-value temp env))))
,@forms))
(defmacro typed-var (var &environment env)
(let ((type (assoc var (symbol-macro-value temp env))))
(if type `(the ,(cadr type) ,var) var)))
)
(defun symbol-macro-value (symbol env &optional default)
(multiple-value-bind (expansion macro-p) (macroexpand symbol env)
(if macro-p (eval expansion) default)))
Opinion is divided as to which is more understandable. Some
people find the COMPILER-LET idiom more understandable (assuming that
it can be made to work consistently in compiled and interpreted
code), while others find it just as natural to use MACROLET or
SYMBOL-MACROLET.
The issues are these:
- Is it possible to implement COMPILER-LET in a usefully consistent
way in all implementations?
- Are the benefits of providing a useful and compatible implementation
of COMPILER-LET worth any associated cost?
Two proposals are presented below:
- Option REPAIR argues that COMPILER-LET provides interesting
functionality that can be implemented in a manner that is usefully
consistent across implementations, and that the associated cost
is low enough for it to be worthwhile to do so.
- Option ELIMINATE argues that COMPILER-LET complicates the language
and that providing this construct is not worth the associated
implementation cost.
Proposal (COMPILER-LET-CONFUSION:REPAIR):
Strike the existing definition of COMPILER-LET. Redefine it as follows:
COMPILER-LET [Special form]
COMPILER-LET is similar to LET, but it always makes special
bindings and makes those bindings visible only during
macroexpansion of forms in the body, not during the runtime
execution of those forms.
The intent is that some macros might macroexpand into calls to
COMPILER-LET in which the body would the contain references to
macros which access the variables in the COMPILER-LET.
The initial value forms of the bindings, if any, are always
evaluated in a null lexical context, regardless of whether the
COMPILER-LET expression is being interpreted or compiled.
The initial value forms of the bindings, if any, are evaluated in
a dynamic context where the bindings of any lexically enclosing
COMPILER-LET are visible, and where dynamic execution-time
environment may or may not be visible.
Implementation Note: Permitting the execution-time dynamic
environment to be visible when initializing COMPILER-LET variables
is a concession to some interpreters which may have to do this in
order to keep the cost down. Where feasible, implementors should
try not to make the runtime environment visible.
Rationale:
This gives a consistent description of COMPILER-LET which separates
issues of intent from those of implementation in a way that makes it
possible for portable code to make serious use of it, and which does
not force gratuitous incompatibilities between interpreters and
compilers.
This description of COMPILER-LET can be implemented without undue
cost by all implementations. See "Cost to Implementors" for details.
Cost to Implementors:
Modest, but nontrivial in some implementations.
In compiled code, and in interpreters doing a one-time semantic
prepass, it should be fairly easy for COMPILER-LET to cause the
variables to get bound (using PROGV) during semantic analysis.
In interpreters which do not do a semantic-prepass, it is necessary
to fully macroexpand the body. Assuming the presence of a
SYSTEM::MACROEXPAND-ALL primitive, the definition of COMPILER-LET
could look like:
(DEFMACRO COMPILER-LET (BINDINGS &BODY FORMS &ENVIRONMENT ENV)
(SETQ BINDINGS ;; Assure no non-atom bindings
(MAPCAR #'(LAMBDA (BINDING)
(IF (ATOM BINDING) (LIST BINDING) BINDING))
BINDINGS))
(PROGV (MAPCAR #'CAR BINDINGS)
(MAPCAR #'CDR BINDINGS)
(SYSTEM::MACROEXPAND-ALL `(PROGN ,@FORMS) ENV)))
This reduces the problem of writing a program capable of doing a
full macroexpansion. Many systems already have such a facility.
Pitman wrote such a facility in Cloe Runtime in order support
SYMBOL-MACROLET (before it was christened a special form); it was
about 750 lines of relatively straightforward, well-commented code.
Cost to Users:
Code currently depending on this feature is either non-existent or
already not portable (due to wide variation in implementation
strategy for COMPILER-LET).
Most users will probably be happy for any interpretation which offers
them a future shot at portability.
Some users have indicated they dislike interpreters which do a semantic
prepass, because they like to be able to dynamically redefine macros
while debugging.
Proposal (COMPILER-LET-CONFUSION:ELIMINATE):
Remove COMPILER-LET from the language.
Rationale:
Some people think that having one less special form would simplify the
language. The revised COMPILER-LET semantics, which require
COMPILER-LET to make special bindings which are only visible during
expansion of macros which appear lexically within its body, are
not shared by any other feature in the language, and require a
fairly complex implementation technique. There are other
constructs which are strictly lexical that can be readily used
to solve the same kinds of problems that COMPILER-LET is intended to
be used for.
Cost to Implementors:
Minimal. Implementations could continue to support COMPILER-LET as
an extension.
Cost to Users:
Code currently depending on this feature is either non-existent or
already not portable (due to wide variation in implementation
strategy for COMPILER-LET).
People who use COMPILER-LET would have to rewrite their programs to use
some other construct. As discussed above, most uses of COMPILER-LET
for communication between macros can be handled using MACROLET or
SYMBOL-MACROLET, though some perspicuity may be lost in the process.
Current Practice:
Some implementations have implemented the description in CLtL.
Users of those implementations (quite reasonably) can't figure how to
use COMPILER-LET and so don't use it much.
Some implementations (the ones from which COMPILER-LET originally came)
continue to use their pre-CLtL semantics. These semantics are useful, though
incompatible with CLtL (which they largely consider to simply be in error).
Users of those implementations probably use COMPILER-LET somewhat more
often since it has an intelligible behavior, but their code is not portable
since it relies on behaviors which are either contrary to or not guaranteed
by CLtL.
Benefits:
Either way, a potential area of incompatibility between compiled and
interpreted code would be eliminated.
Either way, a potential area of portability trouble would be very
drastically reduced (in the case of the REPAIR option) or eliminated
(in the case of the ELIMINATE option).
Discussion:
Pitman strongly favors COMPILER-LET-CONFUSION:REPAIR. He argues
against the idea of using MACROLET instead of COMPILER-LET, saying:
This is a little misleading because it's like saying you can
do without LET given that you have FLET. You can, but you lose some things
in the process:
Just as rewriting a LET using FLET might slow your computation, so too
a rewrite of COMPILER-LET using MACROLET might slow things down. However,
compilation speed is generally not weighted as heavily as execution speed
by many people, so the loss of speed here may not be as important.
Just as rewriting a LET using FLET might obscure the simplicity of your
intent, so too rewriting COMPILER-LET using MACROLET might obscure your
intent. You'd probably get used to recognizing idioms if you used it often
enough. Certainly this would be true if you didn't have LET. However,
COMPILER-LET is used less often, so not having it would mean that the
code you wrote instead would be much harder to read because people
wouldn't have the necessary familiarity with the idioms involved and so
wouldn't always understand them.
Sandra Loosemore responds:
The argument that using MACROLET is more inefficient than COMPILER-LET
is questionable. Both of the suggested implementation techniques for
COMPILER-LET involve considerable overhead.
If COMPILER-LET were not part of the language, people wouldn't think in
terms of rewriting COMPILER-LETs as MACROLETs; instead, they'd think of
how to use MACROLET in the first place to solve their problems. This
is what people who now use implementations with broken COMPILER-LETs
already do. Since MACROLET is now used much more frequently than
COMPILER-LET, that argues that people are much more familiar with
MACROLET idioms than COMPILER-LET idioms.
Also, note that the intent of the revised COMPILER-LET definition is
to make the binding only lexically visible within the body. Using
special binding for this purpose is troublesome. Both the MACROLET
and SYMBOL-MACROLET solutions are completely lexical and avoid all
the problems associated with special binding.
Glenn Burke thinks it needs to be emphasized that the code-walker
mentioned in the REPAIR proposal does not need to be portable. He
says:
The present wording makes it sound like a piece of cake to do with
portable code, when the reality is that a good fraction of CL cleanup
effort has involved the lack of capability of producing such a beast.
Without one or more of a number of proposals being accepted, a fully
correct portable code walker cannot be built, in my belief.
I object to the flippant attitude of just "presupposing" this
"trivial" function which "we know how to do".
∂13-Mar-89 1531 X3J13-mailer **DRAFT** issue DEFCONSTANT-NOT-WIRED, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:30:56 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09104; Mon, 13 Mar 89 16:28:40 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02557; Mon, 13 Mar 89 16:28:37 -0700
Date: Mon, 13 Mar 89 16:28:37 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132328.AA02557@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: **DRAFT** issue DEFCONSTANT-NOT-WIRED, version 6
We don't expect to ask for a vote on this issue -- the writeup is just
being distributed so that we can refer to it in case the issue ever
comes up again. None of the suggestions listed here seemed to have a
great deal of support among people on the cl-compiler list, and all of
them have problems we haven't been able to resolve yet.
Forum: Compiler
Issue: DEFCONSTANT-NOT-WIRED
References: CLtL pages 68-69
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS,
PROCLAIM-LEXICAL,
DECLARE-TYPE-FREE,
DEFCONSTANT-SPECIAL
Category: ADDITION
Edit history: 09 Oct 1988, V1 by David Gray
27 Oct 1988, V2 by David Gray (new proposal)
10 Nov 1988, V3 by David Gray - updated proposal, rationale
and discussion sections in response to comments.
21 Nov 1988, V4 by David Gray - SPECIAL cancels CONSTANT;
CONSTANT doesn't require previous SPECIAL.
28 Nov 1988, V5 by Sandra Loosemore (clean up, fix
some consistency problems)
13 Mar 1989, V6 by Sandra Loosemore (start over)
Status: **DRAFT**
Problem description:
DEFCONSTANT performs two different functions:
- It says that it is an error to SETQ or rebind the variable which
is being defined as a constant.
- It gives the compiler permission to evaluate the initial value form
at compile time, and to build assumptions about the value into
programs being compiled.
In some cases, one would like to have the first behavior without
getting the second. In particular, one would like to get the same
behavior with regard to signalling errors and warnings that you get
with DEFCONSTANT.
Common Lisp provides no mechanism for specifying a variable should
be treated in this way.
Proposal DEFCONSTANT-NOT-WIRED:FIX-DEFPARAMETER:
This is what DEFPARAMETER was supposed to be used for. The description
of DEFPARAMETER needs to be clarified to reflect this, perhaps by
saying that a continuable error should be signalled if an attempt is
made to SETQ or rebind a variable defined with DEFPARAMETER.
Rationale:
DEFPARAMETER apparently derives from Zetalisp's DEFCONST construct,
which was used to indicate that values that would "never" change,
without licensing the compiler to make assumptions about that value.
However, most uses of DEFCONST have apparently been changed to use
DEFCONSTANT instead.
Objections:
Some people don't think that DEFPARAMETER was intended to be used
in this way and that this would be an incompatible change.
Proposal DEFCONSTANT-NOT-WIRED:RESTORE-DEFCONST:
Leave DEFPARAMETER alone but add another construct with the semantics
described above.
Rationale:
Some people don't think that DEFPARAMETER was intended to be used
in this way.
Objections:
We haven't been able to come up with a good name for this construct.
"DEFCONST" is too confusing and all of the other names that have
been suggested are too long. Also, having so many macros for
declaring variables with is confusing.
Proposal DEFCONSTANT-NOT-WIRED:NEW-DECLARATION:
Add a new CONSTANT declaration to the language which can be used to
declare that a variable cannot be SETQ'd or bound within the scope of
the declaration.
Rationale:
This solves the problem and also provides more general functionality.
For example, one could declare that a lexical variable won't be
SETQ'ed.
Objections:
We haven't been able to decide whether a CONSTANT declaration should
augment or replace a SPECIAL or LEXICAL declaration. How do you
initialize a variable that has been proclaimed CONSTANT? Some people
have objected to calling the declaration CONSTANT unless it is
equivalent to what a DEFCONSTANT does.
Proposal DEFCONSTANT-NOT-WIRED:ADD-OPTIONAL-ARGUMENT:
Add an optional argument to DEFCONSTANT to indicate whether the
compiler can make assumptions about the constant's value.
Rationale:
It would solve the problem.
Objections:
It would make DEFCONSTANT have different syntax from DEFVAR and
DEFPARAMETER.
Proposal DEFCONSTANT-NOT-WIRED:DEFINE-VARIABLE
Define a single macro, DEFINE-VARIABLE, that can be used to do what
DEFVAR, DEFPARAMETER, and DEFCONSTANT now do, plus the proposed new
functionality, plus possibly handle lexical variables as well
(if proposal PROCLAIM-LEXICAL passes). Arguments to the macro
could be used to control whether the value is allowed to change
and whether the compiler is allowed to make assumptions about the
value.
Rationale:
It would solve the problem without cluttering up the language with
new defining macros for every possible combination of behavior.
Objections:
Nobody has proposed anything definite yet.
Discussion:
This issue was discussed at length on the cl-compiler mailing list
last fall, without coming up with an acceptable proposal. It didn't
appear that any of the alternatives had a great deal of support. This
writeup summarizes the alternatives that have been proposed at various
times. Some of them (particularly NEW-DECLARATION) have been
considered in detail, and others (DEFINE-VARIABLE) haven't been
pursued at all.
∂13-Mar-89 1533 X3J13-mailer issue DEFINE-OPTIMIZER, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:33:36 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09197; Mon, 13 Mar 89 16:31:22 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02562; Mon, 13 Mar 89 16:31:17 -0700
Date: Mon, 13 Mar 89 16:31:17 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132331.AA02562@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue DEFINE-OPTIMIZER, version 5
Forum: Compiler
Issue: DEFINE-OPTIMIZER
References: Issue SYNTACTIC-ENVIRONMENT-ACCESS
Category: ADDITION
Edit history: 28-Sep-88, Version 1 by Pitman
10-Mar-89, Version 2 by Pitman (clarifications, new example),
10-Mar-89, Version 3 by Pitman & Loosemore
11-Mar-89, Version 4 by Pitman
13-Mar-89, Version 5 by Loosemore (discussion)
Status: Ready for release
Problem Description:
Often a general functional interface could be bypassed given explicit
knowledge of the arguments passed. This may happen when the arguments
are constant (or otherwise inferrable), an argument type is known (eg,
due to use of THE or DECLARE), or when some particular pattern of
optional, rest or keyword arguments is apparent.
Most implementations provide internally for optimization of generalized
function call interfaces to more specialized ones, but such an
optimization facility is not provided to Common Lisp users.
The absence of this facility in a portable fashion means that some
CL programs run slower than they need to in some implementations, or
else that some operators that should be implemented as functions end
up getting implemented as macros to assure needed efficiency.
Proposal (DEFINE-OPTIMIZER:NEW-FACILITY):
Introduce a facility for declaring compiler optimizations.
DEFINE-OPTIMIZER name arglist {declaration}* {form}* [Macro]
Defines a compiler optimizer for a function named NAME. The ARGLIST,
DECLARATIONS, and FORMS are treated exactly like the arglist,
declarations, and forms in a DEFMACRO. (The arglist may include
&ENVIRONMENT and &WHOLE.)
The argument NAME must name a function which has been previously
defined. The effects of defining an optimizer for a locally or
globally defined macro, a locally defined function, or a special
form are undefined.
When the optimizer is invoked, the forms are executed in the context
of bindings specified by the arglist, and two values are yielded,
RESULT and VALID-P. (If either of the first or second return value
is non-NIL, then the first return value is considered valid).
If the result is valid, it is a form which is preferable to evaluate
instead of the indicated call.
If a call to DEFINE-OPTIMIZER appears at top-level in a file
being processed by the file compiler, it also makes the optimizer
known at compile-time (similar to the way DEFMACRO makes a macro
definition known to the compiler).
OPTIMIZE-EXPRESSION-1 form env [Function]
Similar to MACROEXPAND-1. Invokes the optimizers for the top level of
FORM, but does not iterate on the result. Returns two values:
RESULT and CHANGED-P.
Note: If an optimizer returns a result which is not valid,
OPTIMIZE-EXPRESSION-1 hides the fact by returning FORM,NIL
rather than NIL,NIL.
OPTIMIZE-EXPRESSION form env [Function]
Iterates calling OPTIMIZE-EXPRESSION-1 until the CHANGED-P result
is NIL.
An implementation must save optimizer definitions created by
DEFINE-OPTIMIZER in case OPTIMIZE-EXPRESSION is attempted, but is
not actually required to call OPTIMIZE-EXPRESSION itself. Interpreters,
for example, may choose to just call the unoptimized form.
Using FLET and MACROLET shadow not only functions and their SETF methods,
but also their optimizers. No portable facility is provided for creating
locally defined optimizers.
The effect of defining optimizations for functions in the LISP package
is not defined. (In some implementations, this would clobber or conflict
with existing advice that may be of higher quality.)
The editor is advised that a non-binding style note such as the
following would also be appropriate:
In general, it is poor style for a programmer to define optimizers for
functions that he does not maintain. This is because the correct
implementation of an optimizer for a function usually depends on an
understanding of the internals of that function. As such, a function
definition and any optimizers should be maintained as a unit so that
they can changes in either can be synchronized as appropriate with the
other.
The effect of using DEFINE-OPTIMIZER on a function declared to be
INLINE is ``unspecified but harmless'' (per new Error Terminology).
That is, since both operations (optimization and inlining) are intended
to be semantics-preserving, no functional difference should be observed.
However, in some implementations the presence of an optimizer may thwart
the ability to inline, or vice versa. Writers of portable code are
encouraged to use either DEFINE-OPTIMIZER or (PROCLAIM '(INLINE ...))
but not both.
Example:
;; These examples are taken literally from the Macsyma sources,
;; modified only to change DEFOPT to DEFINE-OPTIMIZER. The comments
;; were specially written for the X3J13 audience.
;; M+ is adds a Macsyma expression to another Macsyma expression.
;; The Macsyma internal representation for the sum of X and Y is
;; ((MPLUS) X Y). A all the real work is done by SIMPLIFY, which
;; reduces the expression as needed necessary. However, SIMPLIFY
;; is very complicated, and considerable speed can be gained by
;; entering it at specific known places.
(DEFUN M+ (&REST TERMS)
(PROTECT-&REST-VARIABLE TERMS)
(SIMPLIFY `((MPLUS) ,@TERMS)))
(DEFINE-OPTIMIZER M+ (&REST TERMS)
(COND ((= (LENGTH TERMS) 2) `(ADD2* ,@TERMS))
(T `(ADDN (LIST ,@TERMS) NIL))))
;; M- negates a Macsyma expression, or substracts two Macsyma
;; expressions. Once you figure out which of the two operations is
;; to be done, the problem is similar to that of M+ above. However,
;; often the decision can be made at compile time. In this case,
;; INLINE functions would have worked ok, except that not all
;; implementations do inlining, and even those that do may fail to
;; recognize that EXP2 being NIL means that a test can be eliminated
;; or dead code can be eliminated. Using optimizers is far more
;; likely to be useful in practice.
(DEFUN M- (EXP1 &OPTIONAL (EXP2 NIL EXP2P))
(IF (NOT EXP2P)
(M--INTERNAL-NEGATE EXP1)
(M--INTERNAL-SUBTRACT EXP1 EXP2)))
(DEFINE-OPTIMIZER M- (EXP1 &OPTIONAL (EXP2 NIL EXP2P))
(IF (NOT EXP2P)
`(M--INTERNAL-NEGATE ,EXP1)
`(M--INTERNAL-SUBTRACT ,EXP1 ,EXP2)))
Rationale:
Many large portable applications expect such a facility on an
implementation-specific basis. Others would use one if available.
Even if implementations don't use the provided optimizers primitively,
user macros and code-walkers can invoke them, so the facility wouldn't
be completely useless even in those implementations.
Current Practice:
Symbolics Genera provides an optimizer facility which is more elaborate
but not fundamentally incompatible with this facility.
Many (if not most) serious implementations provide a similar facility.
For example, Lucid provides "compiler macros" which serve the same
purpose.
Cost to Implementors:
Since the implementation is not required to use this facility, the
cost of providing the proposed support is very small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Portable code would be slower than necessary in some situations.
Benefits:
Some existing non-portable code could become portable.
Aesthetics:
Providing a separate optimizer definition from a main function definition
makes a possibility that the optimizer and main function could drift out
of synch. However, most places where this gets used in the first place
are places where speed is of paramount importance and the programmer is
willing to invest effort in maintaining things correctly and to accept the
risk of lossage if s/he fails.
This is a fairly clean and simple extension which adds significant
power to the compiler.
Discussion:
Pitman strongly supports this proposal, the design of which is modeled
directly after that which has been used in Macsyma for many years.
Information about argument type can come from two different sources:
THE and declarations (via PROCLAIM or DECLARE). The former information
is portably accessible, the latter is not. While a separate proposal
(SYNTACTIC-ENVIRONMENT-ACCESS) for allowing program access to type
declarations would be make this facility more useful, it is still
quite useful without it, as the examples from Macsyma illustrate.
Some implementations provide a way to provide more than one optimizer
for the same function. A multiple optimizer facility can be written
in terms of this simpler facility and vice versa, so the simpler of
the two facilities is proposed here.
Some people have suggested that they would like to see a pattern
matching facility integrated into this facility. The design of a
facility that would satisfy everyone would take a lot of time and
effort. At this point, there is no chance that the design of such a
facility would occur in time for acceptance into the standard.
The choice is this or nothing. Pitman thinks the language is much
better off with some form of optimization support than none.
Loosemore says:
Although I don't really think this is an essential feature to include
in the standard, I don't have any strong objection to adding it. If
people think it's a good idea to provide a standard interface for this
kind of thing, this is a good proposal for doing it -- it's fairly
simple, doesn't introduce any radically new ideas, and is general
enough to allow alternate interfaces (such as the pattern matcher) to
be layered on top of it.
Barrett says:
I think you may have gotten the sense of Cris' INLINE comment wrong.
I believe what he was suggesting is that NOTINLINE declarations should
inhibit optimizers, a position I agree with. I also think it would be
better to specify the behavior when both an optimizer and an inline
are present, rather than leaving it 'unspecified but harmless'. I'd
suggest that optimizers have precedence. The rational is that this
allows an optimizer to look for special patterns in the arguments, and
to defer to the inline if it doesn't find them. Of course, there's
the problem that the compiler might then ignore the inline.
∂13-Mar-89 1536 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:36:01 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09314; Mon, 13 Mar 89 16:33:46 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02565; Mon, 13 Mar 89 16:33:44 -0700
Date: Mon, 13 Mar 89 16:33:44 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132333.AA02565@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Forum: Compiler
Issue: DEFINING-MACROS-NON-TOP-LEVEL
References: CLtL p. 66-70, 143
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue COMPILER-LET-CONFUSION
Category: CLARIFICATION, ENHANCEMENT
Edit History: 6-May-88, V1 by Sandra Loosemore
9-Jun-88, V2 by Sandra Loosemore
12-Sep-88, V3 by Sandra Loosemore (fix garbled section 4)
21-Sep-88, V4 by Sandra Loosemore (clarify section 5)
16-Dec-88, V5 by Sandra Loosemore (major restructuring)
31-Dec-88, V6 by Sandra Loosemore (wording clarifications)
07-Jan-89, V7 by Sandra Loosemore (add example)
09-Mar-89, V8 by Sandra Loosemore (more restructuring)
Status: Ready for release
Problem Description:
CLtL leaves the interpretation of defining forms such as DEFMACRO and
DEFVAR that appear in other than top-level locations unclear.
On page 66, it is stated: "It is not illegal to use these forms at
other than top level, but whether it is meaningful to do so depends on
context. Compilers, for example, may not recognize these forms
properly in other than top-level contexts". At least one implementation
has interpreted this to mean that it is permissible to simply refuse
to compile defining macros that do not appear at top-level.
Proposal DEFINING-MACROS-NON-TOP-LEVEL:ALLOW:
(1) Remove the language from p. 66 of CLtL quoted above. Clarify that
while defining macros normally appear at top level, it is meaningful
to place them in non-top-level contexts and that the compiler must
handle them properly in all situations. However, the compile-time side
effects described in issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
only take place when the defining macros appear at top-level.
(2) Remove the language on p. 145 of CLtL, which states that macro
functions are always defined in the null lexical environment. Clarify
that all defining macros which create functional objects (including
DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
DEFSETF, as well as DEFUN) must ensure that those functions are
defined in the lexical environment in which the defining form is
evaluated.
(3) Specify that top-level forms in a file being compiled are
guaranteed to be processed sequentially. The order in which
non-top-level subforms of a top-level form are processed by the
compiler is explicitly left unspecified.
Rationale:
This proposal makes the rules for when defining macros cause
compile-time side effects to be exactly the same as the rules for when
(EVAL-WHEN (COMPILE) ...) causes compile-time evaluation. This
provides a simple implementation technique.
Item (3) serves two purposes. First, it guarantees users that
compile-time side-effects from top-level EVAL-WHEN forms or defining
macros will happen in the correct order; programmers can depend upon
the compile-time side-effects of a top-level form being visible during
the compilation of subsequent forms. Second, it allows compilers to
perform certain kinds of source-to-source transformations that change
the order of subforms.
For instance, the following example from CLtL
(let ((old-count *access-count*))
(unwind-protect
(progn
(incf *access-count*)
(perform-access))
(setq *access-count* old-count)))
is entirely equivalent to:
(let ((old-count *access-count*))
(let ((thunk #'(lambda () (setq *access-count* old-count))))
(unwind-protect
(progn
(incf *access-count*)
(perform-access))
(funcall thunk))))
(This is a real example from the A-Lisp compiler, which implements
UNWIND-PROTECT by having it push a "thunk" to perform the cleanup
actions onto the catch stack before executing the protected form.)
Current Practice:
Most implementations do allow defining macros in non-top-level places.
However, the rules for when they cause compile-time side-effects are
not always the same as those for EVAL-WHEN. This is the case in
Lucid Common Lisp, for example.
Cost to implementors:
Implementations that currently don't compile defining macros correctly
when they appear at non-top-level will have to be changed.
Cost to users:
None. This is a compatible extension.
Benefits:
The notion of defining macros as being somehow special when they
appear at top-level is removed, since their behavior can be explained
using EVAL-WHEN as a primitive. Allowing defining macros to appear
anywhere instead of restricting them to certain positions results in a
cleaner language design.
Discussion:
This proposal is consistent with the behavior specified in proposal
EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL. In particular, if the compile
time side-effects for defining macros specified in proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY are implemented using
EVAL-WHEN, the "right" compiler behavior for defining macros at
non-top-level will happen automatically.
∂13-Mar-89 1545 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:45:11 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09664; Mon, 13 Mar 89 16:42:59 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02574; Mon, 13 Mar 89 16:42:54 -0700
Date: Mon, 13 Mar 89 16:42:54 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132342.AA02574@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue EVAL-WHEN-NON-TOP-LEVEL, version 6
This issue has been giving us a lot of trouble for a long time. A few
people on the cl-compiler mailing list have expressed discontent with
the proposals included here, but the dissenters haven't been able to
come up with an acceptable alternative proposal that they can all agree
on.
Issue: EVAL-WHEN-NON-TOP-LEVEL
Forum: Compiler
References: EVAL-WHEN (CLtL pp69-70),
Issue DEFINING-MACROS-NON-TOP-LEVEL
Issue COMPILED-FUNCTION-REQUIREMENTS
Issue IN-PACKAGE-FUNCTIONALITY
Issue LOCALLY-TOP-LEVEL
Category: CLARIFICATION/CHANGE
Edit History: 06-May-88, Version 1 by Sandra Loosemore
16-Dec-88, Version 2 by Loosemore (alternate direction)
30-Dec-88, Version 3 by Loosemore (minor wording changes)
07-Jan-89, Version 4 by Loosemore (update discussion)
09-Feb-89, Version 5 by Pitman and Moon (some major changes)
09-Mar-89, Version 6 by Loosemore (clean up wording)
Status: Ready for release
Problem Description:
The current description of how the compiler should handle EVAL-WHEN
only makes sense when it appears as a top-level form in the file being
compiled. Is it legitimate for EVAL-WHEN to appear in non-top-level
locations? Even if it is legitimate, what does it mean?
Another issue, referred to here as ``the EVAL-WHEN shadowing problem,''
is that some people have complained that shadowing the symbols EVAL,
COMPILE, or LOAD means that you have to also either shadow EVAL-WHEN
and define it to recognize the new symbol, or else you must resign
yourself to writing (EVAL-WHEN (... LISP:EVAL ...) ...),etc. all over.
While the goal here is not to solve this problem, it might be possible
to solve both problems at once.
There are two proposals presented here, GENERALIZE-EVAL and
GENERALIZE-EVAL-NEW-KEYWORDS.
Background/Analysis:
The proposal which follows was constructed with the following goals
in mind:
1. The lexical and dynamic environment for the EVAL-WHEN body should
be the same for each situation. That is, the body should ``mean
the same thing'' regardless of which situation is being processed.
2. The evaluation context for EVAL-WHEN should be the current
lexical environment.
3. At execution time, EVAL-WHEN should always return the result of
its last form if execution of the body occurred, or NIL if the
body was not executed.
4. If a top-level EVAL-WHEN has a LOAD keyword, its body should
inherit top-level-ness during normal processing. This permits the
use of (EVAL-WHEN (EVAL COMPILE LOAD) ...) at top-level to mean
simply "Do whatever would normally be done for this body, but
also do something at compile time." This, in turn, will later be
the key to allowing defining forms to be usefully described in
terms of EVAL-WHEN.
5. Non-top-level expressions should have no effect until they are
executed. This is the key to making sure that any necessary
environment is present. Since the COMPILE keyword forces effects
to occur earlier than execution time, it follows from this that
any correct solution must not allow the COMPILE keyword to have
an effect at other than top-level.
To accomplish these goals, we formulated the following model:
The purpose of EVAL-WHEN is to accomodate the fact that some of the
semantic processing of an expression may usefully be partitioned
between compile time and run time in some circumstances.
(EVAL-WHEN (EVAL) <code>)
describes a general technique for accomplishing some particular goal
at normal program execution time. However, the pair of expressions
(EVAL-WHEN (COMPILE) <code-A>)
(EVAL-WHEN (LOAD) <code-B>)
can be used to describe an alternate technique for implementing part
of the effect (A) at compile-time, and part of the effect (B) at
load-time.
Proposal (EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL):
Replace the description of EVAL-WHEN with the following:
EVAL-WHEN ({situation}*) {form}* [Special Form]
The body of an EVAL-WHEN form is processed as an implicit PROGN, but
only in the situations listed. Each SITUATION must be a symbol,
either COMPILE, LOAD, or EVAL.
The use of COMPILE and LOAD controls whether and when processing
occurs for top-level forms. The use of EVAL controls whether
processing occurs for non-top-level forms.
The EVAL-WHEN construct may be more precisely understood in terms of
a model of how the file compiler, COMPILE-FILE, processes forms in a
file to be compiled.
Successive forms are read from the file by the file compiler using
READ. These top-level forms are normally processed in what we call
`not-compile-time' mode. There is one other mode, called
`compile-time-too' mode, which can come into play for top-level
forms. The EVAL-WHEN special form is used to annotate a program
in a way that allows the program doing the processing to select
the appropriate mode.
Processing of top-level forms in the file compiler works as follows:
* If the form is a macro call, it is expanded and the result is
processed as a top-level form in the same processing mode
(compile-time-too or not-compile-time).
* If the form is a PROGN form, each of its body forms is
sequentially processed as top-level forms in the same processing
mode.
* If the form is a COMPILER-LET, MACROLET, or SYMBOL-MACROLET,
the file compiler makes the appropriate bindings and recursively
processes the body forms as an implicit top-level PROGN with those
bindings in effect, in the same processing mode.
* If the form is an EVAL-WHEN form, it is handled according to
the following table:
COMPILE LOAD EVAL compile-time-too Action
Yes Yes -- -- Process body in compile-time-too mode
No Yes Yes Yes Process body in compile-time-too mode
No Yes Yes No Process body in not-compile-time mode
No Yes No -- Process body in not-compile-time mode
Yes No -- -- Evaluate body
No No Yes Yes Evaluate body
No No Yes No do nothing
No No No -- do nothing
"Process body" means to process the body as an implicit top-level
PROGN. "Evaluate body" means to evaluate the body forms as in
implicit PROGN in the dynamic execution context of the compiler and
in the lexical environment in which the EVAL-WHEN appears.
* Otherwise, the form is a top-level form that is not one of the
special cases. If in compile-time-too mode, the compiler first
evaluates the form and then performs normal compiler processing
on it. If in not-compile-time mode, only normal compiler
processing is performed. [The nature of this processing is
defined more precisely in issue COMPILED-FUNCTION-REQUIREMENTS.]
Any subforms are treated as non-top-level forms.
For an EVAL-WHEN form that is not a top-level form in the file compiler
(that is, one of: in the interpreter; in COMPILE; or in the file
compiler but not at top-level), if the EVAL situation is specified,
its body is treated as an implicit PROGN. Otherwise, the EVAL-WHEN
form returns NIL.
Clarifications/Consequences:
The following effects are logical consequences of the above proposal:
* It is never the case that the execution of a single EVAL-WHEN
expression will execute the body code more than once.
* The keyword `EVAL' is a misnomer because execution of
the body need not be done by EVAL. In compiled code, such as
(DEFUN FOO () (EVAL-WHEN (EVAL) (PRINT 'FOO)))
the call to PRINT should be compiled.
* Macros intended for use in top-level forms should arrange for all
side-effects to be done by the forms in the macro expansion.
The macro-expander itself should not do the side-effects.
Wrong: (defmacro foo ()
(really-foo)
`(really-foo))
Right: (defmacro foo ()
`(eval-when (compile eval load) (really-foo)))
Adherence to this convention will mean that such macros will behave
intuitively when placed in non-top-level positions.
* Placing a variable binding around an EVAL-WHEN reliably captures the
binding because the `compile-time-too' mode cannot occur (because
introducing a variable binding would mean we were not at top level).
For example,
(LET ((X 3))
(EVAL-WHEN (EVAL LOAD COMPILE) (PRINT X)))
will print 3 at execution [load] time, and will not print anything at
compile time. This is important so that expansions of DEFUN and
DEFMACRO can be done in terms of EVAL-WHEN and can correctly capture
the lexical environment.
(DEFUN BAR (X) (DEFUN FOO () (+ X 3)))
might expand into
(DEFUN BAR (X)
(PROGN (EVAL-WHEN (COMPILE)
(COMPILER::NOTICE-FUNCTION-DEFINITION 'FOO '(X)))
(EVAL-WHEN (EVAL LOAD)
(SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA () (+ X 3))))))
which would be treated the same as
(DEFUN BAR (X)
(SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA () (+ X 3))))
by the above rules.
Test Cases:
;; #1: The EVAL-WHEN in this case is not at top-level, so only the EVAL
;; keyword is considered. At compile time, this has no effect.
;; At load time (if the LET is at top level), or at execution time
;; (if the LET is embedded in some other form which does not execute
;; until later) this sets (SYMBOL-FUNCTION 'FOO1) to a function which
;; returns 1.
(LET ((X 1))
(EVAL-WHEN (EVAL LOAD COMPILE)
(SETF (SYMBOL-FUNCTION 'FOO1) #'(LAMBDA () X))))
;; #2: If this expression occurs at the top-level of a file to be compiled,
;; it has BOTH a compile time AND a load-time effect of setting
;; (SYMBOL-FUNCTION 'FOO2) to a function which returns 2.
(EVAL-WHEN (EVAL LOAD COMPILE)
(LET ((X 2))
(EVAL-WHEN (EVAL LOAD COMPILE)
(SETF (SYMBOL-FUNCTION 'FOO2) #'(LAMBDA () X)))))
;; #3: If this expression occurs at the top-level of a file to be compiled,
;; it has BOTH a compile time AND a load-time effect of setting the
;; function cell of FOO3 to a function which returns 3.
(EVAL-WHEN (EVAL LOAD COMPILE)
(SETF (SYMBOL-FUNCTION 'FOO3) #'(LAMBDA () 3)))
;; #4: This always does nothing. It simply returns NIL.
(EVAL-WHEN (COMPILE)
(EVAL-WHEN (COMPILE)
(PRINT 'FOO4)))
;; #5: If this form occurs at top-level of a file to be compiled, FOO5 is
;; printed at compile time. If this form occurs in a non-top-level
;; position, nothing is printed at compile time. Regardless of context,
;; nothing is ever printed at load time or execution time.
(EVAL-WHEN (COMPILE)
(EVAL-WHEN (EVAL)
(PRINT 'FOO5)))
;; #6: If this form occurs at top-level of a file to be compiled, FOO6 is
;; printed at compile time. If this form occurs in a non-top-level
;; position, nothing is printed at compile time. Regardless of context,
;; nothing is ever printed at load time or execution time.
(EVAL-WHEN (EVAL LOAD)
(EVAL-WHEN (COMPILE)
(PRINT 'FOO6)))
Rationale:
This is compatible with any guarantees made by CLtL, and extends the
behavior usefully to non-top-level situations.
This gives a useful meaning to EVAL-WHEN that supports useful and
predictable behavior if defining macros are used in a non-top-level
situation.
Proposal (EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS):
As in GENERALIZE-EVAL, but rename the EVAL keyword to :EXECUTE,
the COMPILE keyword to :COMPILE-TOPLEVEL, and LOAD keyword to
:LOAD-TOPLEVEL.
Deprecate the use of keywords EVAL, COMPILE, and LOAD to EVAL-WHEN.
For compatibility, they are supported in EVAL-WHEN
at top-level, but their meaning is not defined elsewhere.
Rationale:
The fact that the situation keywords chosen are not the same as
those now used means that the change can be added in a way that
is truly upward compatible (not only with CLtL but with existing
practice in implementations which have chosen to extend or `clarify'
the definition given in CLtL) since the meaning of EVAL, COMPILE,
and LOAD in non-top-level situations (which was never spelled
out in CLtL) can legitimately differ from the meaning of these
new keywords.
Using other names and/or the keyword package for the names of
situations solves the EVAL-WHEN shadowing problem.
The name `execute' does not promote the confusion that the body of an
EVAL-WHEN must be executed only in the evaluator. It also does not
promote the confusion that the body of an EVAL-WHEN, regardless of when
executed, must run interpreted.
The names `compile-toplevel' and `load-toplevel' emphasize the fact
that these cases are not interesting in non-top-level positions.
Current Practice:
In Symbolics Genera, the interpreter permits EVAL-WHEN in non-top-level
positions in a way that is compatible with this proposal but both the
COMPILE and COMPILE-FILE functions complain about EVAL-WHEN in a
non-top-level position.
Both Lucid Common Lisp and Kyoto Common Lisp already interpret the
EVAL keyword to mean "execute" in non-top-level situations. Both of
these implementations also make (EVAL-WHEN (LOAD) ...) suppress
compile-time "magic" from defining macros such as DEFMACRO.
IIM describes its EVAL-WHEN as:
(defmacro eval-when (situations &body body &environment env)
(if (not (compiler-environment-p env))
(when (member 'eval situations) `(progn ,@body))
(progn
(when (member 'compile situations)
(if (compiler-at-top-level-p env)
(mapc #'eval body)
(warn "Top-level form encountered at non-top-level.")))
(when (member 'load situations) `(progn ,@body)))))
Note that the interpretation of the EVAL situation and the nesting
behavior is different.
Cost to Implementors:
The actual change to EVAL-WHEN in both cases is probably fairly
localized and straightforward to make in most or all implementations.
The second-order costs of proposal GENERALIZE-EVAL will vary depending
on whether existing implementations have extended the definition of
EVAL-WHEN in incompatible ways. If an implementation has made such
extensions, there may be user and system code which depends on them
and the cost of converting that code may be non-trivial. There is
presumably also documentation impact.
Proposal GENERALIZE-EVAL-NEW-KEYWORDS avoids most or all of the
second-order costs of proposal GENERALIZE-EVAL.
The compiler processing for top-level forms might be implemented
something like:
;;; Forms read by the file compiler are passed to PROCESS-TOP-LEVEL-FORM
;;; with a env compile-time-too both NIL.
(defun process-top-level-form (form env compile-time-too)
(setq form (macroexpand form env))
(cond ((not (consp form))
nil)
((eq (car form) 'progn)
(dolist (f (cdr form))
(process-top-level-form f env compile-time-too)))
((eq (car form) 'compiler-let)
(process-compiler-let form env compile-time-too))
((eq (car form) 'macrolet)
(process-macrolet form env compile-time-too))
((eq (car form) 'symbol-macrolet)
(process-symbol-macrolet form env compile-time-too))
((eq (car form) 'eval-when)
(process-eval-when form env compile-time-too))
(t
(if compile-time-too
(internal-eval form env))
(compile-form form env))
))
(defun process-eval-when (form env compile-time-too)
(let* ((situations (cadr form))
(body (cddr form))
(compile-p (member 'compile situations))
(load-p (member 'load situations))
(eval-p (member 'eval situations)))
(cond ((or (and compile-p load-p)
(and eval-p load-p compile-time-too))
(process-top-level-form `(progn ,@body) env t))
(load-p
(process-top-level-form `(progn ,@body) env nil))
((or compile-p
(and eval-p compile-time-too))
(dolist (f body)
(internal-eval f env)))
(t
nil))))
;;; PROCESS-COMPILER-LET, PROCESS-MACROLET, and PROCESS-SYMBOL-MACROLET
;;; do the obvious things.
;;; INTERNAL-EVAL evaluates "form" in lexical environment "env".
Cost to Users:
Technically, none. Either proposal is technically upward compatible
with CLtL.
Proposal GENERALIZE-EVAL might force some extended implementations to
change incompatibly. As such, some users who depend on
implementation-dependent extensions might have to adjust their code
somewhat to deal with those changes.
Proposal GENERALIZE-EVAL-NEW-KEYWORDS does not force implementations
to change incompatibly, so has no forced impact on users.
Cost of Non-Adoption:
EVAL-WHEN is a mess. Using it as the low-level substrate into which
defining macros should expand, and guaranteeing any predictable effects
of those macros in non-top-level situations is currently difficult and
would continue to be so in the absence of some resolution on this issue.
Benefits:
The costs of non-adoption would be avoided: it would be possible to
use EVAL-WHEN in many situations where it cannot currently be used
reliably.
The portability of many existing tools which use EVAL-WHEN internally
in macros will be enhanced.
Aesthetics:
This generalization of the meaning makes the purpose and uses of
EVAL-WHEN less mysterious. In that sense, aesthetics are simplified
somewhat.
Discussion:
The cleanup issue LOCALLY-TOP-LEVEL would make LOCALLY also "pass
through" top-level-ness to its body. The reason why that is not
addressed in this issue is that it involves making LOCALLY a special
form.
Pitman and Moon don't care whether we say `top level,' `top-level,' or
`toplevel.' The spelling choices in this writeup are arbitrary. If
necessary, the proposal GENERALIZE-EVAL-NEW-KEYWORDS could be amended
to propose :COMPILE-TOP-LEVEL, etc.
Pitman, Moon, and Bob Laddaga (a Symbolics Cloe implementor) support
both of these proposals. Pitman and Laddaga have a preference for
GENERALIZE-EVAL-NEW-KEYWORDS. Moon is neutral about which should be
preferred.
Sandra Loosemore says:
I still feel somewhat uncomfortable with the definition of EVAL-WHEN
presented here, mostly because its nesting behavior is so unintuitive
(as in test case number 6). We have also had a hard time in deciding
what the term "top-level" really means; the definition presented here
is rather arbitrary. However, since we have run out of time in which
to come up with acceptable alternatives, I'm willing to go along with
proposal GENERALIZE-EVAL. It is compatible with the description in
CLtL but presented in a more coherent way, and I think it is an
improvement. On the other hand, I don't really like the idea of
changing the names of the keywords; if we are going to make an
incompatible change, the right thing to do would be to throw out
EVAL-WHEN entirely and start from scratch.
∂13-Mar-89 1601 X3J13-mailer **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:57:19 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA10215; Mon, 13 Mar 89 16:55:08 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02585; Mon, 13 Mar 89 16:55:05 -0700
Date: Mon, 13 Mar 89 16:55:05 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132355.AA02585@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
This issue is still under discussion. There are three proposals
presented formally and two more mentioned informally in the discussion
section, but it appears that the decision is really between proposal
DYNAMIC and everything else.
Forum: Compiler
Issue: MACRO-ENVIRONMENT-EXTENT
References: CLtL p. 145-146
Issue COMPILER-LET-CONFUSION
Issue MACRO-CACHING
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue SYNTACTIC-ENVIRONMENT-ACCESS
CLOS Chapter 3 (89-003)
Category: CLARIFICATION,CHANGE
Edit History: V1, 10 Jan 1989, Sandra Loosemore
V2, 09 Mar 1989, Sandra Loosemore
V3, 13 Mar 1989, Sandra Loosemore (last-minute discussion)
Status: **DRAFT**
Problem Description:
What is the extent of environment objects received as the &ENVIRONMENT
argument of a macro function?
CLtL says that &ENVIRONMENT is "useful primarily in the rare cases
where a macro definition must explicitly expand any macros in a
subform of the macro call before computing its own expansion". While
this suggests that macro environment objects are typically used within
the dynamic scope of the macro function, the use of the word
"primarily" (rather than "only" or "exclusively" or some similarly
strong language) suggests that there may be other legitimate uses for
environment objects. But, because CLtL is silent about what those
uses might be, many users and implementors are under the impression
that environment objects have only dynamic extent.
There are some situations where using environment objects as if they
had indefinite extent provides a very useful viewpoint from which to
solve a problem. Consider the following example:
(defmacro typed-var (var) var)
(defmacro local-type-declare (declarations &body forms &environment env)
`(macrolet ((typed-var (&whole w var)
(let ((type (assoc var ',declarations)))
(if type
`(the ,(cadr type) ,var)
(macroexpand w ',env)))))
,@forms))
(defun f (x y)
(local-type-declare ((x fixnum) (y float))
(+ (typed-var x) (typed-var y))))
Here, local macro TYPED-VAR is defined to look first in the innermost
lexical environment for information about the variable, and if there
isn't any then it recurses on the next outermost lexical environment.
The global definition of TYPED-VAR provides a terminal case to stop
the recursion.
There are other situations where the extent of macro environment
objects comes into play. For example, if we allow caching of macro
expansions (issue MACRO-CACHING), environments must have indefinite
extent. It is unclear whether CLOS would be affected by allowing
macro environments to have only dynamic extent. (The descriptions of
the CLOS defining macros in document 89-003 seem to imply that the
value of the &ENVIRONMENT argument appears in the expansion of the
macro, but there now seems to be sentiment that the model of how the
defining macros work that is presented there is broken.)
Proposal MACRO-ENVIRONMENT-EXTENT:INDEFINITE:
State that macro environment objects received with the &ENVIRONMENT
argument of a macro function or as the argument to a *MACROEXPAND-HOOK*
function have indefinite extent.
Note that implementations are not permitted to destructively modify
lexical information in environment objects once they have been passed
to a macro function. It is, however, permissible to add or remove
global definitions that are accessible through the environment.
Rationale:
This legitimizes the use of idioms which depend on macro environments
having indefinite extent.
Since data objects in Lisp otherwise have indefinite extent, it is
more consistent to give environment objects indefinite extent as
well.
Proposal MACRO-ENVIRONMENT-EXTENT:DYNAMIC:
State that macro environment objects received with the &ENVIRONMENT
argument of a macro function or with a *MACROEXPAND-HOOK* function
have only dynamic extent; the consequences are undefined if they are
referred to outside the dynamic extent of that macro function or hook
function.
Rationale:
This allows implementations to use somewhat more efficient techniques
for representing environment objects. For example, the storage could
be stack-allocated, or environments could be bashed destructively
instead of always being freshly heap-allocated.
Proposal MACRO-ENVIRONMENT-EXTENT:DYNAMIC-WITH-COPIER:
State that macro environment objects received with the &ENVIRONMENT
argument of a macro function or with a *MACROEXPAND-HOOK* function
have only dynamic extent; the consequences are undefined if they are
referred to outside the dynamic extent of that macro function or hook
function.
Add a new function:
COPY-ENVIRONMENT environment [function]
This function returns an environment object that is semantically
equivalent to "environment" (which must be an object of the type
received with an &ENVIRONMENT argument to a macro or as an argument to
a *MACROEXPAND-HOOK* function), but which may safely be referred to
outside the dynamic extent of the macro function. This function is
permitted to return an object that is EQ to its argument if that
object may be safely used.
Rationale:
This allows implementations to use somewhat more efficient techniques
for representing environment objects. For example, the storage could
be stack-allocated, or environments could be bashed destructively
instead of always being freshly heap-allocated.
It also allows programmers to use idioms that rely on environment
objects having indefinite extent.
Current Practice:
Macro environments appear to have indefinite extent in Lucid Common
Lisp, Kyoto Common Lisp, CMU Common Lisp (at least in the
interpreter), Utah Common Lisp, and A-Lisp. A-Lisp internally uses
the kind of idiom shown in the example above to implement FLET,
LABELS, and FUNCTION as macros.
Macro environments are stack-allocated in Symbolics Genera, and hence
have dynamic extent.
Macro environments also have dynamic extent on the TI Explorer,
because the compiler uses special variables are used to keep track of
lexical definitions.
Cost to implementors:
For proposal INDEFINITE, some implementations would need to change. A
simple implementation of macro environments that would fit the
requirements of this proposal is to represent them as lists, pushing
information for inner contours onto the front of the list as the
contour is entered and popping the list when the contour is exited.
For proposal DYNAMIC, there is no associated implementation cost.
For proposal DYNAMIC-WITH-COPIER, the implementation cost is unknown
but probably fairly small in most implementations.
Cost to users:
For proposal INDEFINITE, there is no associated cost to users.
For proposal DYNAMIC, users would not be able to portably use a
simple and elegant approach to solving certain kinds of problems.
For proposal DYNAMIC-WITH-COPIER, users would have to remember to make
a copy of an environment object in some situations.
Benefits:
It is made clear whether treating environment objects as if they had
indefinite extent is portable usage.
Discussion:
Proposal SYNTACTIC-ENVIRONMENT-ACCESS:ADD-FUNCTIONAL-INTERFACE
includes adding a function called AUGMENT-ENVIRONMENT which could also
be used to create a copy of an environment. However, it returns an
object with the same extent as its argument, and therefore can not
replace the function COPY-ENVIRONMENT under proposal
DYNAMIC-WITH-COPIER.
We have also considered a couple of other alternatives on this
issue.
One alternative would be to give "remote" environments created by
COMPILE-FILE the extent of that call to COMPILE-FILE, while "local"
environments (the null lexical environment and environments created by
COMPILE and EVAL) would have indefinite extent.
Another alternative would be to say that environments created by
COMPILE-FILE, COMPILE, or EVAL have a dynamic extent that includes the
time when any other macro calls appearing lexically within the
expansion returned by the macro function are expanded. This is
similar to the extent of the special bindings made by COMPILER-LET.
Both of these proposals could be combined with adding a copier
function to deal with those implementations where environments are
stack-allocated. They would both solve the extent problem for the
example given in the problem description section, but not the general
problem of macro caching. In conjunction with the proposals for issue
SYNTACTIC-ENVIRONMENT-ACCESS, they would both require some
modifications to implementations that currently give macro
environments dynamic extent.
Loosemore supports proposal MACRO-ENVIRONMENT-EXTENT:INDEFINITE.
Moon says:
My opinion is that anything in CLOS that seems to depend on indefinite
extent for macro environments is broken and needs to be fixed. It's not
broken because of the environment extent, but for other reasons.
Thus I believe in dynamic extent for environments.
Neil Goldman says:
In my code walker I have a pretty ugly way of dealing with MACROLET
that would have been trivial if I could have counted on the
ENVIRONMENT having indefinite extent. There may be some cleaner way
than what I did, but I just looked at PCL's code walker, and it also
is much more complex than would be necessary if environments had
indefinite extent.
∂13-Mar-89 1610 X3J13-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:10:26 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA10862; Mon, 13 Mar 89 17:08:13 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02608; Mon, 13 Mar 89 17:08:10 -0700
Date: Mon, 13 Mar 89 17:08:10 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903140008.AA02608@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
This is a new writeup for an issue that was first brought up several
months ago. We haven't had time to review it thoroughly yet.
Issue: PROCLAIM-ETC-IN-COMPILE-FILE
References: CLtL p. 182 [package functions],
p. 156 [PROCLAIM], p. 439 [COMPILE-FILE];
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue IN-PACKAGE-FUNCTIONALITY
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION, CHANGE, ADDITION
Edit History: 15 Sep 88, V1 by David Gray
23 Sep 88, V2 by Sandra Loosemore (summarize discussion)
11 Mar 89, V3 by Sandra Loosemore (rewrite)
13 Mar 89, V4 by Sandra Loosemore (discussion)
Status: **DRAFT**
Problem Description:
Should the compiler treat top-level calls to PROCLAIM specially?
Page 182 of CLtL says that COMPILE-FILE needs to treat top-level calls
to the following package functions as though they were wrapped in an
(EVAL-WHEN (COMPILE LOAD EVAL) ...):
EXPORT IMPORT IN-PACKAGE MAKE-PACKAGE SHADOW
SHADOWING-IMPORT UNEXPORT UNUSE-PACKAGE USE-PACKAGE
CLtL is silent on whether top-level calls to PROCLAIM should also be
evaluated at compile-time, which presumably means they shouldn't be.
However, some implementations do evaluate PROCLAIM at compile-time.
In the model of how COMPILE-FILE works that is presented in issues
EVAL-WHEN-NON-TOP-LEVEL and DEFINING-MACROS-NON-TOP-LEVEL, the special
form EVAL-WHEN is the only thing that can cause compile-time evaluation
to occur. The compile-time side-effects of macros such as DEFMACRO
and DEFPACKAGE are explained by having them include EVAL-WHEN in their
expansions. Any functions that are treated specially, however, must
be included as special cases in the compiler.
Proposal IN-PACKAGE-FUNCTIONALITY:NEW-MACRO would remove the
requirement that the package functions be treated specially. Do we
wish to make an exception to the model for PROCLAIM?
Proposal PROCLAIM-ETC-IN-COMPILE-FILE:YES:
Require COMPILE-FILE to treat top-level calls to PROCLAIM as if they
were wrapped in an (EVAL-WHEN (COMPILE LOAD EVAL) ...).
Rationale:
Proclamations affect compilation semantics and should be made
available to the compiler.
Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NO:
Clarify that calls to PROCLAIM should be treated the same as any
other function call. Users should wrap an explicit EVAL-WHEN around
top-level calls to PROCLAIM if they want them to affect compilation.
Rationale:
This makes the semantics of COMPILE-FILE more uniform and easier
to understand. In particular, if we remove the magic compile-time
behavior of the package functions, it seems silly to add another
exception for PROCLAIM.
Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO:
Add a new macro:
DEFPROCLAIM &rest decl-specs [Macro]
This macro PROCLAIMs the given <decl-specs>, which are not
evaluated. If a call to this macro appears at top-level in a file
being processed by the file compiler, the proclamations are also
made at compile-time. As with other defining macros, it is
unspecified whether or not the compile-time side-effects of a
DEFPROCLAIM persist after the file has been compiled.
Clarify that calls to PROCLAIM should be treated the same as any
other function call. Users should wrap an explicit EVAL-WHEN around
top-level calls to PROCLAIM if they want them to affect compilation,
or use the macro DEFPROCLAIM.
Rationale:
The macro makes the proclamations available to the compiler in such
a way that does not require any special exceptions to be made in
the model of how COMPILE-FILE works.
Current Practice:
The TI explorer apparently implements proposal YES, except that
(EVAL-WHEN (LOAD) (PROCLAIM '(OPTIMIZE ...))) doesn't do anything.
The Symbolics compiler has special top-level handling for PROCLAIM,
although the details are not clear.
Lisps developed at Utah (UCL, A-Lisp, PSL/PCLS) do not give PROCLAIM
any special compile-time handling.
Lucid does not evaluate calls to PROCLAIM at compile-time.
The IIM compiler has special top-level handling for PROCLAIM when
the argument is a constant. The information is recorded in the remote
environment.
Cost to implementors:
Since implementations are already required to have a mechanism for
compile-time handling of the package functions, it would probably
only require minor adjustments to add handling for PROCLAIM.
Cost to users:
For proposal YES, users would have no way to suppress compile-time
evaluation of a top-level call to PROCLAIM. Wrapping it in an
(EVAL-WHEN (EVAL LOAD)...) wouldn't work under the model of how
EVAL-WHEN works in proposal EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL.
Under any of these proposals, some users would probably have to
make minor changes to their code.
Benefits:
Users will know what to expect when they use PROCLAIM.
Costs of Non-Adoption:
Users will not know what to expect when they use PROCLAIM.
Aesthetics:
At least two people consider requiring magic behavior for certain
top-level function calls to be "semantically bletcherous". Removing
all special cases for functions that are implicitly evaluated at
compile-time would simplify the model of how COMPILE-FILE works.
Programs look cleaner if EVAL-WHEN is only needed for unusual cases
instead of being required for the normal cases.
Discussion:
The first version of this writeup also included REQUIRE with PROCLAIM,
but we have now voted to remove REQUIRE from the language entirely.
It also specified that OPTIMIZE proclamations should only have a local
effect within the file being compiled. This was removed for
consistency with other compile-time side-effects (such as those from
DEFMACRO), where their persistence is explicitly left unspecified.
Loosemore favors proposal NO, but wouldn't oppose proposal NEW-MACRO.
Kim Barrett says:
Proposal YES violates the general approach we've been taking of trying
to limit side-effects on the local environment during compilation.
Proposal NO makes PROCLAIM virtually worthless.
Proposal NEW-MACRO -- While this matches up with other stuff we've
been doing, I'm concerned about two things. First, I really dislike
the name DEFPROCLAIM. This thing isn't defining anything! It sounds
like something that modifies the behavior of PROCLAIM, not something
that actually makes a proclamation. Second, I'm concerned about the
cost to users. I think the statement that
"Under any of these proposals, some users would probably have to make
minor changes to their code."
is rather misleading for this case. There are a lot of PROCLAIMs out
there.
Loosemore replies:
....but all of those uses of PROCLAIM are already nonportable. No
matter what we do here, somebody is going to get burned.
Suggestions for better names for the macro are welcome.
∂13-Mar-89 1627 X3J13-mailer issue WITH-COMPILATION-UNIT, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:27:44 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11422; Mon, 13 Mar 89 17:25:34 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02634; Mon, 13 Mar 89 17:25:31 -0700
Date: Mon, 13 Mar 89 17:25:31 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903140025.AA02634@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue WITH-COMPILATION-UNIT, version 3
Forum: Compiler
Issue: WITH-COMPILATION-UNIT
References: COMPILE (p438), COMPILE-FILE (p439)
Category: ADDITION
Edit history: 29-Sep-88, Version 1 by Pitman
10-Mar-89, Version 2 by Pitman (merge comments)
13-Mar-89, Version 3 by Loosemore (update discussion)
Status: Ready for release
Problem Description:
Some actions done by the compiler (and particularly the file compiler)
are typically deferred until the "very end" of compilation. For example,
some compilers complain about "functions seen but not defined".
Unfortunately, since COMPILE-FILE is the largest unit of granularity,
and since systems often extend over more than one file, it often happens
that the compiler needlessly complains at the end of compiling one file
about the absence of functions defined in the next file.
Proposal (WITH-COMPILATION-UNIT:NEW-MACRO):
Add the following new macro:
WITH-COMPILATION-UNIT options &BODY forms [Macro]
Executes forms from left to right. Within the dynamic context
of this form, actions deferred by the compiler until "the end of
compilation" will be deferred until the end of the outermost call
to WITH-COMPILATION-UNIT. The result(s) are the same as that of
the last of the FORMS (or NIL if FORMS is null).
OPTIONS is a keyword/value list, where only the values are
evaluated. The set of keywords permitted may be extended by the
implementation, but the only keyword defined by this standard is:
:OVERRIDE boolean
The default is NIL. If nested dynamically only the outer call
to WITH-COMPILATION-UNIT has any effect unless BOOLEAN is T,
in which case warnings are deferred only to the end of the
innermost call.
It follows that the functions COMPILE and COMPILE-FILE should
provide the effect of (WITH-COMPILATION-UNIT (:OVERRIDE NIL) ...)
around their code.
Any implementation-dependent extensions may only be provided
as the result of an explicit programmer request by use of
an implementation-dependent keyword. Implementations are forbidden
from attaching additional meaning to a conforming use of this
macro.
Note also that not all warnings are deferred. In some implementations,
it may be that none are deferred. This proposal only creates an
interface to the capability where it exists, it does not require the
creation of the capability. An implementation which does not do
deferred warnings may correctly implement this as expanding into PROGN.
Test Case:
(DEFUN COMPILE-FILES (&REST FILES)
(WITH-COMPILATION-UNIT ()
(MAPCAR #'(LAMBDA (FILE) (COMPILE-FILE FILE)) FILES)))
(COMPILE-FILES "A" "B" "C")
processes deferred warnings only after compiling all of A, B, and C.
Rationale:
This will make the development of portable system-construction tools
considerably more convenient.
Current Practice:
Lucid has a very similar facility, called WITH-DEFERRED-WARNINGS.
TI Explorer and Symbolics Genera have a similar facility, which they
call COMPILER-WARNING-CONTEXT-BIND.
Cost to Implementors:
In implementations which have no deferred warnings, there is no cost.
In implementations which have deferred warnings, the cost is probably
fairly small -- usually just a matter of writing interfacing the
proposed macro to an existing one.
Cost to Users:
None. This is a compatible addition.
Cost of Non-Adoption:
Portable system-construction tools would continue to print lots of
spurious warnings because they would have no way to tell the system
that a set of files was working together.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
The ability to create a compilation unit other than a file is important.
Discussion:
Pitman and Benson support this addition.
One could imagine adding more options at a later date.
It was the opinion of the compiler committee that there was room for
expansion here to address issues like bounding the scope of global
proclamations, sharing compile-time environments across files, etc.
However, insufficient work was done on this to justify putting such
a thing into the standard. The only clear need we have at this time
was to defer warnings, but we chose a general name like
WITH-COMPILATION-UNIT rather than a specific name like Lucid's
WITH-DEFERRED-WARNINGS in order to encourage implementations to
experiment with other kinds of options under implementation-specific
keywords. Perhaps by the time of the next standard there will be
sufficient understanding of this area to warrant further elaboration
of this primitive.
Kim Barrett says:
I strongly oppose the behavior you proposed for compile and
compile-file. It is my belief that whether to override or not must be
controlled through an argument to the compile functions, with the
default being to override. Otherwise, all existing code which makes
use of the compile functions must be modified to protect itself by
wrapping a (with-compilation-unit (:override t) ...) around the calls
to the compiler.
Consider a stream system built on an object system which will compose
and compile functions on the fly on an as needed basis. It would be
very strange for the functions so generated while doing file io for
the user's compile-file to have any relationship with said
compile-file.
I agree with your position that implementation-dependent extensions
must be explicitly requested.
∂13-Mar-89 1622 X3J13-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:22:04 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11265; Mon, 13 Mar 89 17:19:53 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02631; Mon, 13 Mar 89 17:19:48 -0700
Date: Mon, 13 Mar 89 17:19:48 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903140019.AA02631@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
This issue is also still under discussion. This version of the writeup
is fairly new and hasn't been reviewed thoroughly yet.
Forum: Compiler
Issue: SYNTACTIC-ENVIRONMENT-ACCESS
References: CLtL Chapter 8: Macros,
Issue MACRO-FUNCTION-ENVIRONMENT,
Issue GET-SETF-METHOD-ENVIRONMENT,
Issue COMPILE-FILE-ENVIRONMENT
Related Issues: Issue FUNCTION-NAME,
Issue PROCLAIM-LEXICAL
Issue MACRO-ENVIRONMENT-EXTENT
Category: ADDITION
Edit history: Version 1, 2-Oct-88, Eric Benson
Version 2, 17-Feb-89, Kim A. Barrett
Version 3, 9-Mar-89, Kim A. Barrett (respond to comments)
Version 4, 12-Mar-89, Sandra Loosemore (more revisions)
Status: **DRAFT**
Problem description:
When macro forms are expanded, the expansion function is called with
two arguments: the form to be expanded, and the environment in which
the form was found. The environment argument is of limited utility.
The only use sanctioned currently is as an argument to MACROEXPAND or
MACROEXPAND-1 or passed directly as an argument to another macro
expansion function. Recent cleanup issues propose to allow it as an
argument to MACRO-FUNCTION and to GET-SETF-METHOD.
It is very difficult to write a code walker that can correctly handle
local macro and function definitions, due to insufficient access to
the information contained in environments and the inability to
augment environments with local definitions.
Some people believe that the CLOS meta-object protocol will require the
ability to distinguish between remote environments used for compiling
to a file, from local environments used for processing by EVAL or
COMPILE. (However, there is no requirement in chapters 1 & 2 of the
CLOS spec that things be done this way.)
There are three proposals; SMALL, MEDIUM, and LARGE.
Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:SMALL):
The following functions provide information about syntactic
environment objects. In all of these functions the argument named ENV
is an environment of the sort received by the &ENVIRONMENT argument to
a macro or as the environment argument for EVALHOOK. Optional "env"
arguments default to NIL, which respresents the local null lexical
environment (containing only global definitions and proclamations
that are present in the runtime environment). All of these functions
should signal an error of type TYPE-ERROR if the value of an
environment argument is not a syntactic environment.
VARIABLE-KIND variable &optional env [Function]
VARIABLE is a symbol. This function returns one of the following
symbols, depending on the type of definition or binding which is
apparent in ENV.
NIL There is no apparent definition or binding for variable.
:SPECIAL VARIABLE refers to a special variable, either declared
or proclaimed.
:LEXICAL VARIABLE refers to a lexical variable.
:SYMBOL-MACRO VARIABLE refers to a SYMBOL-MACROLET binding.
:CONSTANT VARIABLE refers to a named constant, defined by
DEFCONSTANT.
[Note: If issue PROCLAIM-LEXICAL passes, then the :LEXICAL result
will also refer to variables proclaimed lexical.]
Example:
(DEFMACRO KIND-OF-VARIABLE (VAR &ENVIRONMENT ENV)
`',(VARIABLE-KIND VAR ENV))
(DEFVAR A)
(DEFUN TEST ()
(LET (B)
(LET (C)
(DECLARE (SPECIAL C))
(SYMBOL-MACROLET ((D ANYTHING))
(LIST (KIND-OF-VARIABLE A)
(KIND-OF-VARIABLE B)
(KIND-OF-VARIABLE C)
(KIND-OF-VARIABLE D)
(KIND-OF-VARIABLE E))))))
(TEST) -> (:SPECIAL :LEXICAL :SPECIAL :SYMBOL-MACRO NIL)
FUNCTION-KIND function &optional env [Function]
FUNCTION is a function name. This function returns two values,
depending on the type of function definition or function binding
which is apparent for FUNCTION in ENV.
NIL There is no apparent definition for FUNCTION.
:FUNCTION FUNCTION refers to a function.
:MACRO FUNCTION refers to a macro.
:SPECIAL-FORM FUNCTION refers to a special form.
The second value specifies whether the definition is local or
global. If local, the second value is true, and it is false when
the definition is global.
Some function names may refer to both a global macro and a global
special form. In such a case, the macro takes precedence, and
:MACRO is returned as the first value.
[Note: The use of "function name" rather than "symbol" as the
description of the function argument is intended to be compatible
with the various proposals to extend the syntax of function
specifiers. If no such change actually occurs then this would only
refer to symbols.]
Example:
(DEFMACRO KIND-OF-FUNCTION (FUNCTION-NAME &ENVIRONMENT ENV)
`',(FUNCTION-KIND FUNCTION-NAME ENV))
(DEFUN A ())
(DEFMACRO B ())
(DEFUN TEST ()
(FLET ((C ()))
(MACROLET ((D ()))
(MULTIPLE-VALUE-CALL #'LIST
(KIND-OF-FUNCTION A)
(KIND-OF-FUNCTION B)
(KIND-OF-FUNCTION QUOTE)
(KIND-OF-FUNCTION C)
(KIND-OF-FUNCTION D)
(KIND-OF-FUNCTION E)))))
(TEST) -> (:FUNCTION NIL
:MACRO NIL
:SPECIAL-FORM NIL
:FUNCTION T
:MACRO T
NIL NIL)
VARIABLE-TYPE variable &optional env [Function]
VARIABLE is a symbol. This function returns the type specifier
associated with the variable named by the symbol in the environment.
If no explicit association exists, either by PROCLAIM or DECLARE,
then the result is the type specifier T.
The result of this function may not include all the apparent TYPE
declarations for VARIABLE. In particular, an implementation is free
to ignore TYPE declarations, only returning TYPE information which
was added to ENV by a call to AUGMENT-ENVIRONMENT.
Example:
This example assumes that the implementation records type
information in the environment, rather than ignoring it.
(DEFMACRO VARTYPE (VAR &ENVIRONMENT ENV)
`',(VARIABLE-TYPE VAR ENV))
(DEFVAR A 1)
(PROCLAIM '(FIXNUM A))
(DEFUN TEST ()
(LET ((B (AREF "X" 0))
(C 3))
(DECLARE (STRING-CHAR B))
(LIST (VARTYPE A) (VARTYPE B) (VARTYPE C))))
(TEST) -> (FIXNUM STRING-CHAR NIL)
FUNCTION-FTYPE function &optional env [Function]
FUNCTION is a function name. This function returns the functional
type specifier associated with the function in the environment, or
the symbol FUNCTION if there is no functional type declaration or
proclamation associated with the function.
The result of this function may not include all the apparent FTYPE
declarations for FUNCTION. In particular, an implementation is free
to ignore FTYPE declarations, only returning FTYPE information which
was added to ENV by a call to AUGMENT-ENVIRONMENT.
Example:
This example assumes that the implementation records ftype
information in the environment, rather than ignoring it.
(DEFMACRO FUNTYPE (FUN &ENVIRONMENT ENV)
`',(FUNCTION-FTYPE FUN ENV))
(DEFUN A-FUNCTION (X)
(+ X 3))
(PROCLAIM '(FTYPE (FUNCTION (FIXNUM) FIXNUM) A-FUNCTION))
(DEFUN TEST ()
(FLET ((ANOTHER-FUNCTION (X)
(+ X 2)))
(DECLARE (FTYPE (FUNCTION (INTEGER) INTEGER) ANOTHER-FUNCTION))
(LIST (FUNTYPE A-FUNCTION) (FUNTYPE ANOTHER-FUNCTION))))
(TEST) -> ((FUNCTION (FIXNUM) FIXNUM) (FUNCTION (INTEGER) INTEGER))
AUGMENT-ENVIRONMENT env &KEY variable
symbol-macro
function
macro
declare [Function]
This function returns a copy of ENV, augmented with the information
provided by the keyword arguments. The arguments are supplied as
follows:
:VARIABLE A list of symbols which shall be visible as bound
variables in the new environment. Whether each
binding is to be interpreted as special or lexical
depends on SPECIAL declarations recorded in the
environment or provided in the :DECLARE argument list.
:SYMBOL-MACRO A list of symbol macro definitions, in the same format
as the CADR of a SYMBOL-MACROLET special form. The
new environment will have local symbol-macro bindings
of each symbol to the corresponding expansion, so that
MACROEXPAND will be able to expand them properly.
:FUNCTION A list of function names which shall be visible as local
function bindings in the new environment.
:MACRO A list of local macro definitions, in the same format
as the CADR of a MACROLET special form. The new
environment will have local macro bindings of each
name to the corresponding expander function, which
will be returned by MACRO-FUNCTION and used by
MACROEXPAND.
:DECLARE A list of decl-specs. The new environment will
contain information about SPECIAL, TYPE, and FTYPE
declarations appearing within the list.
An error is signalled if any of the symbols naming macros in the
:SYMBOL-MACRO alist are also included in the :VARIABLE list.
An error is signalled if any of the names specified as keys in the
:MACRO alist are also included in the :FUNCTION list. The consequences
of destructively modifying the list structure of any of the arguments
to this function are undefined.
The extent of the returned environment is the same as the extent of
the argument.
While an environment argument from EVALHOOK may be used as the
environment argument for this function, the reverse is not true. If
an attempt is made to use the result of AUGMENT-ENVIRONMENT as
the environment argument for EVALHOOK, the consequences are undefined.
The environment returned by AUGMENT-ENVIRONMENT may only be used for
syntactic analysis, ie. the functions specified by this proposal and
functions such as MACROEXPAND.
[If PROCLAIM-LEXICAL is adopted, LEXICAL declarations would also
be recognized.]
Rationale:
This proposal defines a minimal set of accessors and a constructor
for environments.
The symbol-macro and macrolet definitions and declarations passed
to AUGMENT-ENVIRONMENT are in the same form as those which would
normally be encountered by a code-walker. This makes it easier to
use. In particular, there is no need for users to write their own
code to destructure macro arguments.
Making TYPE and FTYPE information optional continues to allow
implementations the freedom to simply ignore all such declarations.
Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:MEDIUM):
This is the same as proposal SMALL, but also includes:
There are two kinds of environments, local and remote. Local
environments are created by EVAL and COMPILE, and are used in
situations where the information in the environment pertains
to the immediate running Lisp environment. Remote environments
are used by processors such as COMPILE-FILE to model what the
Lisp environment will look like when the code being processed
is actually loaded.
If AUGMENT-ENVIRONMENT receives a remote environment as an argument,
then the new environment returned by this function will also be
remote, and the two will refer to the same model of the remote
environment.
ENVIRONMENT-REMOTE-P env [Function]
Returns true if ENV is a remote environment, false otherwise.
WITH-REMOTE-ENVIRONMENT var &body body [Macro]
Evaluates the BODY forms with VAR bound to a newly created remote
environment. The extent of the environment is the dynamic extent of
the WITH-REMOTE-ENVIRONMENT form.
This is the only specified mechanism by which a new remote
environment may be created.
Rationale:
The notion of local and remote environments may be useful for
developing the CLOS meta-object protocol. At some future time,
we may wish to tighten the specification of how compile-time
definitions of defining macros such as DEFMACRO or DEFCLASS are
achieved, by saying that the compile-time definitions must be made
only in the remote environment.
Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:LARGE):
This is the same as proposal MEDIUM, but also includes:
ENVIRONMENT-PROPERTY env name property &optional default
This function and its SETF method allow the association of arbitrary
'global' properties with names within an environment. An
environment can be thought of as having a local property list
associated with any name, and this function provides access to that
property list.
A remote environment may be thought of as an extension of the local
environment. Thus, when this function is applied to a remote
environment and the property is not found, the global local environment
is then searched.
The association between names and property lists uses EQUAL to match
names. The search of the property list uses EQ to match properties.
If the property is not found, DEFAULT is returned.
Using SETF of ENVIRONMENT-PROPERTY affects all environments which
refer to the same environment model. In particular, if ENV is a
local environment then all local environments are affected, while if
ENV is a remote environment, then all environments refering to the
same remote environment model as the argument are affected.
[Note: The local property list of a name is not necessarily the
symbol-plist of the name, though that is a possible implementation
for names which are symbols.
Note: The use of EQUAL as the matching function for names is to
allow for proposed extensions to function names. If no such
extension occurs, then EQ could be used instead.]
Rationale:
This would provide a mechanism for making and accessing global
definitions in the remote environment.
Cost to Implementors:
Most implementations already record some of this information in some
form. Providing these functions should not be too difficult, but it
is a more than trivial amount of work.
Cost to Users:
This change is upward compatible with user code.
Current practice:
No implementation provides all of this interface currently. Portable
Common Loops defines a subset of this functionality for its code
walker and implements it on a number of diffent versions of Common
Lisp. IIM uses the functionality provided by ENVIRONMENT-REMOTE-P
and ENVIRONMENT-PROPERTY (under other names) to implement the
association between names and remote metaobjects (macro and type
definitions, CLOS remote metaobjects, &etc).
Discussion:
The first version of this proposal expressly did not deal with the
objects which are used as environments by EVALHOOK. This version is
extended to support them in the belief that such environments share a
lot of functionality with the syntactic environments needed by a
compiler. While the two types of environments may have very
different implementations, there are many operations which are
reasonable to perform on either type, including all of the accessor
functions described by this proposal.
AUGMENT-ENVIRONMENT currently requires signaling an error when
symbol-macro names match variable names in the same call. This could
be reduced to "should signal". By requiring the error signaling, this
proposal is compatable with Proposal SYMBOL-MACROLET-DECLARE:ALLOW,
which says
"... signals an error if a SPECIAL declaration names one of the symbols
being defined as a symbol-macrolet."
Maintaining compatability with the SYMBOL-MACROLET-DECLARE proposal
allows fairly trivial implementations of the SYMBOL-MACROLET
special-form in terms of the AUGMENT-ENVIRONMENT function.
An possible alternative syntax for WITH-REMOTE-ENVIRONMENT might be
WITH-REMOTE-ENVIRONMENT (var &key) &body body
Can anyone suggest candidates for keyword options? We could do this
even if we can't think of any immediately, leaving room for
implementation-specific extensions. One candidate option that some
implementations might want would be to specify a target machine for
the compilation.
Kim Barrett originally suggested that WITH-COMPILATION-UNIT should
provide the mechanism for creating new remote environments. However,
it has been suggested that WITH-COMPILATION-UNIT is intended to serve
a somewhat different purpose.
Sandra Loosemore says:
I support proposal SMALL but would vote against both of the larger
proposals. It's true that they provide functionality which *might* be
useful to implement CLOS, but there is nothing now in the standard
that *requires* this functionality to be added. In fact, the version
of issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS that was accepted at
the January meeting explicitly leaves unspecified the mechanism by
which defining macros make definitions available to the compiler. We
have very little practical experience with using environment objects
for this purpose and I think it would be premature to try to
standardize it at this point. In particular, since the meta-object
protocol is still undergoing what appear to be substantial changes,
let's wait until it settles down and then see what kind of compiler
hooks it needs, instead of possibly standardizing the wrong thing.
∂13-Mar-89 1643 X3J13-mailer issue COMPILER-LET-CONFUSION, version 7
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:43:27 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 19:39:46 EST
Date: Mon, 13 Mar 89 19:41 EST
From: Barry Margolin <barmar@Think.COM>
Subject: issue COMPILER-LET-CONFUSION, version 7
To: cl-compiler@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132314.AA02546@defun.utah.edu>
Message-Id: <19890314004109.1.BARMAR@OCCAM.THINK.COM>
Date: Mon, 13 Mar 89 16:14:26 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
In interpreters which do not do a semantic-prepass, it is necessary
to fully macroexpand the body. Assuming the presence of a
SYSTEM::MACROEXPAND-ALL primitive, the definition of COMPILER-LET
could look like:
(DEFMACRO COMPILER-LET (BINDINGS &BODY FORMS &ENVIRONMENT ENV)
(SETQ BINDINGS ;; Assure no non-atom bindings
(MAPCAR #'(LAMBDA (BINDING)
(IF (ATOM BINDING) (LIST BINDING) BINDING))
BINDINGS))
(PROGV (MAPCAR #'CAR BINDINGS)
(MAPCAR #'CDR BINDINGS)
(SYSTEM::MACROEXPAND-ALL `(PROGN ,@FORMS) ENV)))
Modulo some bugs in the code. Shouldn't the second-to-last line be:
(MAPCAR #'(LAMBDA (BINDING)
(eval (CaDR BINDING)))
BINDINGS)
(my additions are in lowercase)?
barmar
∂13-Mar-89 1634 X3J13-mailer summary of active cl-compiler issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:34:43 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11546; Mon, 13 Mar 89 17:32:30 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02645; Mon, 13 Mar 89 17:32:27 -0700
Date: Mon, 13 Mar 89 17:32:27 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903140032.AA02645@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: summary of active cl-compiler issues
Here is a list of all the active cl-compiler issues. Writeups for
all of these were mailed out earlier today.
CLOS-MACRO-COMPILATION (**DRAFT** version 2)
Clarify compile-time behavior of CLOS defining macros.
Proposal MINIMAL
Proposal NOT-SO-MINIMAL
(Still under active discussion.)
COMPILE-ENVIRONMENT-CONSISTENCY (version 4)
What kinds of things can/must the compiler "wire in" to the code
it compiles?
Proposal CLARIFY
COMPILE-FILE-SYMBOL-HANDLING (version 2)
How does COMPILE-FILE tell LOAD what package to put symbols in?
Proposal CURRENT-PACKAGE
Proposal HOME-PACKAGE
Proposal REQUIRE-CONSISTENCY
COMPILED-FUNCTION-REQUIREMENTS (version 4)
What does the COMPILED-FUNCTION type imply? Do COMPILE and
COMPILE-FILE construct COMPILED-FUNCTIONs?
Proposal TIGHTEN
Proposal TIGHTEN-COMPILE
COMPILER-DIAGNOSTICS (version 9)
Clarify status and handling of errors and warnings signalled during
compilation.
Proposal USE-HANDLER
COMPILER-LET-CONFUSION (version 7)
The description of COMPILER-LET in CLtL is broken -- should we fix
it or eliminate it entirely?
Proposal REPAIR
Proposal ELIMINATE
COMPILER-VERBOSITY (version 6)
Mechanisms for controlling progress messages issued by the compiler.
Proposal LIKE-LOAD
CONSTANT-CIRCULAR-COMPILATION (version 7)
Must circular or recursive objects be compiled correctly? Must the
compiler preserve sharing of substructures?
Proposal NO
Proposal PRESERVE-SHARING-ONLY
Proposal YES
(Expect amendment to change error terminology.)
CONSTANT-COLLAPSING (version 5)
Should the compiler be allowed to "collapse" or coalesce constants
that satisfy a more general equivalence relationship than EQUAL?
Proposal GENERALIZE
CONSTANT-COMPILABLE-TYPES (version 8)
What types of objects can appear as quoted or self-evaluating constants
in compiled code?
Proposal SPECIFY
(Expect amendments to change requirements for functions.)
DEFCONSTANT-NOT-WIRED (**DRAFT** version 6)
How do you delcare a variable to be constant without giving the
compiler permission to make assumptions about its value?
(None of the proposals are ready to be voted on. This issue
is being distributed only for informational purposes.)
DEFINE-OPTIMIZER (version 5)
Provide a macro-like way of specifying source-level optimizations
on function calls.
Proposal NEW-FACILITY
DEFINING-MACROS-NON-TOP-LEVEL (version 8)
Are defining macros such as DEFUN meaningful in non-top-level locations?
Proposal ALLOW
EVAL-WHEN-NON-TOP-LEVEL (version 6)
What does EVAL-WHEN mean when it appears in non-top-level locations?
Proposal GENERALIZE-EVAL
Proposal GENERALIZE-EVAL-NEW-KEYWORDS
LOAD-TIME-EVAL (version 11)
Add a new special form, LOAD-TIME-VALUE.
Proposal R**2-NEW-SPECIAL-FORM
Proposal R**3-NEW-SPECIAL-FORM
(Proposal R**2-NEW-SPECIAL-FORM was approved at the January meeting,
but some additional suggestions were made after the meeting.)
MACRO-CACHING (version 2)
Is it legitimate to cache macro expansions?
Proposal DISALLOW
Proposal RESTRICT
MACRO-ENVIRONMENT-EXTENT (**DRAFT** version 3)
Do environment objects received as the &ENVIRONMENT argument to a
macro have dynamic or indefinite extent?
Proposal INDEFINITE
Proposal DYNAMIC
Proposal DYNAMIC-WITH-COPIER
(Still under active discussion.)
PROCLAIM-ETC-IN-COMPILE-FILE (**DRAFT** version 4)
Are top-level calls to PROCLAIM handled specially by the compiler?
Proposal YES
Proposal NO
Proposal NEW-MACRO
(New rewrite.)
QUOTE-SEMANTICS (version 2) (replaces QUOTE-MAY-COPY)
May COMPILE and EVAL construct equivalent copies of quoted or
self-evaluating constants, or must constants share structure with
the source code for the program? Do the constraints on what objects
are valid constants also apply to COMPILE and EVAL, or only to
COMPILE-FILE?
Proposal NO-COPYING
Proposal COPYING-ALLOWED-BUT-NO-CONSTRAINTS
Proposal SAME-AS-COMPILE-FILE
SAFE-CODE (version 1)
What does the "safe code" mean?
Proposal SAFETY-3
SYNTACTIC-ENVIRONMENT-ACCESS (**DRAFT** version 4)
Provide accessors and constructors for lexical environment objects.
Proposal SMALL
Proposal MEDIUM
Proposal LARGE
(New rewrite.)
WITH-COMPILATION-UNIT (version 3)
Provide a way to compile a group of files as a unit for the purposes
of error messages.
Proposal NEW-MACRO
∂14-Mar-89 0938 CL-Compiler-mailer issue COMPILER-LET-CONFUSION, version 7
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 09:37:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556615; Tue 14-Mar-89 12:35:04 EST
Date: Tue, 14 Mar 89 12:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-LET-CONFUSION, version 7
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132314.AA02546@defun.utah.edu>
Message-ID: <19890314173505.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I generally favor the COMPILER-LET-CONFUSION:REPAIR proposal, however
I have a couple of comments and questions. Also of course I would want
to see the typo that BarMar found fixed.
What is the interaction between proposals COMPILER-LET-CONFUSION
and DEFINE-OPTIMIZER? Neither proposal says anything about that
as far as I can see. I believe the body of a optimizer must be
executed in the same dynamic environment as the body of a macro.
Cost to Implementors:
In interpreters which do not do a semantic-prepass, it is necessary
to fully macroexpand the body.
This is not true. A possible implementation technique for such
interpreters, in fact the one I would use, is to save the COMPILER-LET
bindings in a slot in the interpreter's lexical environment in the form
of an alist, and to make the MACROEXPAND-1 function bind those bindings
with PROGV around its call to the macroexpander. Using this technique
instead of fully macroexpanding the body deals with some of the
objections to the REPAIR proposal, I believe. Also promoting this
technique in the proposal would remove the need for the discussion
section to address the side-issue of whether code analyzing programs can
or cannot be written portably (an important issue in its own right, but
not part this one).
Current Practice:
Some implementations have implemented the description in CLtL.
Users of those implementations (quite reasonably) can't figure how to
use COMPILER-LET and so don't use it much.
Some implementations (the ones from which COMPILER-LET originally came)
continue to use their pre-CLtL semantics. These semantics are useful, though
incompatible with CLtL (which they largely consider to simply be in error).
Could you be more explicit about this? I was unable to figure out what you
are talking about, even after twice reading the introductory portion of the
proposal and the writeup in CLtL. I believe Symbolics Genera is one of those
implementations from which COMPILER-LET originally came and at the same time
implements COMPILER-LET exactly as CLtL specifies, so I must be missing some
important distinction. I'd like to see a precise description of these two
competing semantics and I'd also like to know which, if either, of them is
compatible with the REPAIR proposal.
∂14-Mar-89 0956 CL-Compiler-mailer issue DEFINE-OPTIMIZER, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 09:56:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556621; Tue 14-Mar-89 12:54:02 EST
Date: Tue, 14 Mar 89 12:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINE-OPTIMIZER, version 5
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132331.AA02562@defun.utah.edu>
Message-ID: <19890314175403.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I generally like DEFINE-OPTIMIZER:NEW-FACILITY, but I would like
to suggest a couple of changes.
I'm not a fan of documentation strings, but shouldn't DEFINE-OPTIMIZER
allow them? Was their omission accidental or intentional?
Instead of returning two values from the body, I suggest returning one
value, or NIL to decline to optimize. If an optimizer wishes to
optimize into a form whose result is NIL, it should return (QUOTE NIL).
After all, if it wishes to optimize into a form whose result is FOO, it
has to return (QUOTE FOO), not FOO. The two values returned by
OPTIMIZE-EXPRESSION-1 are okay, since they are compatible with the two
values returned by MACROEXPAND-1. A reasonable alternative would be to
eliminate the two values at all levels, and also eliminate the special
casing of NIL, and simply specify that one declines to optimize by
returning the original form (compared with EQ). This will work but is
slightly more awkward for the optimizer writer, since &WHOLE would
have to be used. I'd accept this alternative if more people are in
favor of it, but I prefer special-casing NIL. I'd greatly prefer either
of those alternatives over what the proposal says now.
It isn't made clear whether OPTIMIZE-EXPRESSION returns one value
or two. It should be consistent with OPTIMIZE-EXPRESSION-1.
Using FLET and MACROLET shadow...
I assume it was only accidental that LABELS, GENERIC-LABELS, and
GENERIC-FLET were omitted from this list. I am unable to figure
out whether WITH-ADDED-METHODS should be included in this list
or not; I suspect not.
The similar Symbolics Genera facility allows more than one optimizer
to be defined for a given function; the optimizers are invoked in
unspecified order until one succeeds. This feature is actually
used, however I think it is okay to leave it out.
I agree with Barrett's comments quoted in the discussion section.
I'd like to see the proposal amended the way he suggests.
∂14-Mar-89 1005 CL-Compiler-mailer issue WITH-COMPILATION-UNIT, version 3
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 10:05:29 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556623; Tue 14-Mar-89 13:03:02 EST
Date: Tue, 14 Mar 89 13:03 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue WITH-COMPILATION-UNIT, version 3
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903140025.AA02634@defun.utah.edu>
Message-ID: <19890314180303.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I oppose this because I don't think it's finished, however I expect I
would support it if it were finished. It may be that the amount of work
required to finish this is small and the proposal just needs amending.
I don't think it's acceptable to have something like this if its effect
is only defined for warnings, and its effect on compile-time
proclamations, compile-time macro definitions, compile-time defconstant
definitions, compile-time optimizer definitions, compile-time type
definitions, compile-time setf definitions, and compile-time CLOS
definitions is left unspecified.
I think lumping COMPILE and COMPILE-FILE together here reflects
confusion. COMPILE and COMPILE-FILE have very little to do with each
other, and I think it's clear that COMPILE should not be affected in any
way by WITH-COMPILATION-UNIT. Having COMPILE affected by
WITH-COMPILATION-UNIT is as unreasonable as having MACROEXPAND affected
by WITH-COMPILATION-UNIT, if you ask me. I think removing COMPILE would
address Barrett's complaint in the discussion section; that is, I think
having COMPILE-FILE not override an enclosing WITH-COMPILATION-UNIT is
correct.
∂14-Mar-89 1217 CL-Compiler-mailer **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 12:17:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556715; Tue 14-Mar-89 15:09:52 EST
Date: Tue, 14 Mar 89 15:09 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132355.AA02585@defun.utah.edu>
Message-ID: <19890314200952.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I strongly favor MACRO-ENVIRONMENT-EXTENT:DYNAMIC over any of the other four.
∂14-Mar-89 1232 CL-Compiler-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 12:32:34 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556743; Tue 14-Mar-89 15:29:24 EST
Date: Tue, 14 Mar 89 15:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903140008.AA02608@defun.utah.edu>
Message-ID: <19890314202917.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO, primarily because this
allows programs to be clear about the scope of the proclamation:
whether they are making a proclamation for purposes of compile-file or
to affect the running Lisp. If you call the macro at top-level, you're
clearly doing it for compilation. If you call the function at any level,
you're clearly doing it with global scope.
In PROCLAIM-ETC-IN-COMPILE-FILE:NO there is no way to say whether a
PROCLAIM inside an (EVAL-WHEN (COMPILE...) ...) is intended to persist
after the compilation is over, which is just about the only reason
why I prefer PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO over :NO.
I'd like PROCLAIM-ETC-IN-COMPILE-FILE:NO better if it also proposed
to add an optional argument to PROCLAIM that expressed the intended
scope of the proclamation. I'd suggest NIL (the default) for the
global scope and the symbol COMPILE-FILE to limit it to the compilation.
Given this, users who liked DEFPROCLAIM could trivially write it
themselves.
The only thing PROCLAIM-ETC-IN-COMPILE-FILE:YES has going for it is
that it's the status quo, in a subset of implementations. I don't like it.
I agree with Barrett's comments quoted in the discussion section.
The proposal says:
As with other defining macros, it is
unspecified whether or not the compile-time side-effects of a
DEFPROCLAIM persist after the file has been compiled.
but never says this about PROCLAIM. In all three proposals,
this needs to be said about PROCLAIM. But as you can see from my
comments above, I would rather that we did not leave this unspecified.
The proposal says:
Current Practice:
The Symbolics compiler has special top-level handling for PROCLAIM,
although the details are not clear.
I'm not sure what you thought was not clear. Symbolics Genera does the
same thing that the current practice section says IIM does. In addition
(and I couldn't tell whether IIM does this too or not), the scope of the
PROCLAIM is only the compilation-unit if the PROCLAIM appears at
top-level, but is global and persists forever if the PROCLAIM appears in
an (EVAL-WHEN (COMPILE...) ...). We might change that.
∂14-Mar-89 1310 CL-Compiler-mailer issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:09:32 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556774; Tue 14-Mar-89 15:58:28 EST
Date: Tue, 14 Mar 89 15:58 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132333.AA02565@defun.utah.edu>
Message-ID: <19890314205826.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor DEFINING-MACROS-NON-TOP-LEVEL:ALLOW except for one thing.
This sentence appears in the proposal but does not appear to have
any relation to the main issue:
The order in which
non-top-level subforms of a top-level form are processed by the
compiler is explicitly left unspecified.
I can't figure out what this means and the example in the rationale
section that purports to explain this does not shed any light, since in
the example there is no change of order of evaluation. I wouldn't be
surprised if I opposed this if I did understand what it means. Can we
deal with this as a separate issue? In fact the whole point (3) of the
proposal should be moved. That issue should also discuss whether there
are any constraints on whether one top-level form is processed before
the next top-level form is read, in case the one form changes package,
changes readtable, defines a read-syntax, or defines a structure used in
#S read-syntax.
Also, when you say:
Clarify
that all defining macros which create functional objects (including
DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
DEFSETF, as well as DEFUN) must ensure that those functions are
defined in the lexical environment in which the defining form is
evaluated.
I strongly believe that MACROLET must be consistent with this, which
would be a change. Has that been dealt with as a separate issue? If
not, it should either be added to this issue or brought up as a
separate issue, with the interdependency noted in both writeups to
minimize the chance of an inconsistent vote.
∂14-Mar-89 1326 CL-Compiler-mailer issue COMPILE-FILE-SYMBOL-HANDLING, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:25:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556792; Tue 14-Mar-89 16:23:12 EST
Date: Tue, 14 Mar 89 16:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 2
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132312.AA02542@defun.utah.edu>
Message-ID: <19890314212313.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor COMPILE-FILE-SYMBOL-HANDLING:CURRENT-PACKAGE.
COMPILE-FILE-SYMBOL-HANDLING:HOME-PACKAGE seems superficially simpler,
but my experience when we tried it at MIT indicates that it does not
work very well. Too often a symbol that had been moved from one package
to another, or had its export status changed, would be silently moved
back to its original package by loading a file. I sort-of agree with
JonL's comment at the end of the discussion section: if we can't agree
on one solution to his issue, I think that in practice there would be
little harm to portable programs if we left it unspecified. The issue
really affects development environments much more than it affects the
language in which portable programs are written, although it does have
some effect on that as well.
∂14-Mar-89 1340 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:40:33 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 556802; 14 Mar 89 16:37:50 EST
Date: Tue, 14 Mar 89 16:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132250.AA02499@defun.utah.edu>
Message-ID: <19890314213750.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
All the things I didn't like in version 3 have been fixed.
I would favor COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY if one change
were made. The proposal says:
Except where some other behavior is explicitly stated, when
the compiletime and runtime definitions are different, it is
unspecified which will prevail within the compiled code.
This means that either the compiletime or the runtime definition
will prevail, but nothing else can happen. It must also be
permissible to signal an error complaining about the discrepancy.
∂14-Mar-89 1351 CL-Compiler-mailer issue SAFE-CODE, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:51:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556829; Tue 14-Mar-89 16:49:05 EST
Date: Tue, 14 Mar 89 16:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue SAFE-CODE, version 1
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131726.AA02193@defun.utah.edu>
Message-ID: <19890314214907.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I agree with SAFE-CODE:SAFETY-3.
I disagree with the usage (in the examples) of "unsafe code" to mean
"all code where the OPTIMIZE quality of SAFETY is not 3." I believe
that "unsafe code" should mean code that is actually unsafe, not code
that an implementation is permitted to treat as unsafe if it wishes. I
believe there should be no portable way to write unsafe code. This is
only a matter of wording. If we need a shorter term for "all code where
the OPTIMIZE quality of SAFETY is not 3" I would suggest "potentially
unsafe code."
∂14-Mar-89 1357 CL-Compiler-mailer issue COMPILER-VERBOSITY, version 6
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:56:56 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556842; Tue 14-Mar-89 16:54:22 EST
Date: Tue, 14 Mar 89 16:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-VERBOSITY, version 6
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131546.AA02078@defun.utah.edu>
Message-ID: <19890314215423.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I like COMPILER-VERBOSITY:LIKE-LOAD. This fixes all of the
problems I had with the version 5 proposal.
Like BarMar, I question the need for either of :PRINT and :VERBOSE in
either of LOAD and COMPILE-FILE. But that might be my own cultural
bias, due to the type of systems I use, where it's easy to see what's
going on inside. If other people claim they need these, I'll believe
them.
∂14-Mar-89 1419 X3J13-mailer Issue: ERROR-NOT-HANDLED (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 14:19:42 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 14:03:50 PST
Date: 14 Mar 89 14:02 PST
From: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
Subject: Issue: ERROR-NOT-HANDLED (Version 1)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890314-140350-1917@Xerox>
Cleanup issues for the next meeting will be tricking out over the next
week.
This issue was distributed prior to the October 1988 meeting,
but not voted on.
!
Issue: ERROR-NOT-HANDLED
References: Interactive Condition Handling (Condition System, Rev 18, p19)
Category: CLARIFICATION/CHANGE
Edit history: 25-Sep-88, Version 1 by Pitman
Problem Description:
For delivery purposes, some implementations will want to leave out
major sections of runtime support in programs that do not require
them. The debugger is one such section.
However, since ERROR may be called implicitly by a number of Common
Lisp built-in functions, and since the condition system as currently
described insists that the interactive debugger be entered if a
condition is unhandled, the interactive debugger must be retained in
a saved image of any program that might signal an error unless the
compiler can prove that the error will never go unhandled. This
may be undesirable in some cases and may cause unnecessary bloating
of the saved image.
Proposal (ERROR-NOT-HANDLED:PERMIT-TERMINATION):
Permit implementors to designate an implementation-specific mechanism
for asking that unhandled errors cause `termination of the running
program' rather than entry into the system's debugger.
Implementations choosing to offer such a facility must clearly define
the nature and scope of such program termination, since the concept
of `program termination' is an ill-defined concept in present-day
Common Lisp.
Even when program termination rather than debugger entry would be
the ultimate effect of an unhandled error, the value of
*DEBUGGER-HOOK* (if non-NIL) must be called to provide programmers
the ability of customized debugging.
All implementations must at least provide the option of a system
debugger for use in program development.
Test Case:
(ERROR "Foo"), if unhandled, must now enter the debugger.
Under this proposal, it might also `terminate program execution'
in implementations which choose to provide such a facility and to
clearly define that concept.
Rationale:
Although technically an incompatible change, we're dealing at
the very edge of what the user can expect from the system. Once
an error is signalled and not handled, we're in the domain of
implementation-dependent effect anyway.
Current Practice:
Probably no one does this yet.
Cost to Implementors:
None. This change is upward compatible with existing implementations.
Cost to Users:
None.
Cost of Non-Adoption:
Saved Lisp images might be forced to be gratuitously larger than
they need to be in some implementations.
Benefits:
Addressing this issue will make Lisp more able to compete with
other languages which permit small saved images to result from
small user programs.
Aesthetics:
No significant impact.
Discussion:
This change was requested by Christian Queinnec of France
(queinnec@inria.inria.fr). Pitman supports the change.
∂14-Mar-89 1438 CL-Compiler-mailer issue COMPILER-DIAGNOSTICS, version 9
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 14:38:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556909; Tue 14-Mar-89 17:35:56 EST
Date: Tue, 14 Mar 89 17:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-DIAGNOSTICS, version 9
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131545.AA02075@defun.utah.edu>
Message-ID: <19890314223550.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor COMPILER-DIAGNOSTICS:USE-HANDLER, but there are two
things that I think need to be changed:
Conditions of type WARNING may be signalled by the compiler in
situations where ... the compiler can determine
that a situation that "is an error" would result at runtime.
We don't use the term "is an error" any more, do we? In the old
CLtL terms, I think both "is an error" and "signals an error"
situations would justify a warning. I think this part should
be updated to the new error terminology and also should state that
all error situations justify warnings. Of course explicit calls
to the function ERROR don't justify warnings; I don't know whether
the proposal can be phrased in such a way as to make that clear,
or whether it will have to be left to common sense.
(3) Require COMPILE and COMPILE-FILE to handle the ABORT restart by
aborting the smallest feasible part of the compilation.
I think this is wrong. The only documentation of the ABORT restart
that I could find says
The purpose of the ABORT restart is generally to allow return to the
innermost ``command level.''
I agree with this, and I believe it means that it is wrong for any
function other than one that establishes a read-eval-print loop or
a command-level to establish an ABORT restart. It would be useful
to have some restart that aborts a portion of the compilation, but
it should be given some other name.
∂14-Mar-89 1505 CL-Cleanup-mailer Issue: ERROR-NOT-HANDLED (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 15:04:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556941; Tue 14-Mar-89 18:02:30 EST
Date: Tue, 14 Mar 89 18:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-NOT-HANDLED (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu
In-Reply-To: <890314-140350-1917@Xerox>
Message-ID: <19890314230224.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
ERROR-NOT-HANDLED:PERMIT-TERMINATION is okay with me. I would
also support a proposal to replace "the condition system as currently
described insists that the interactive debugger be entered if a
condition is unhandled" with wording that allowed implementations
to do whatever they want, with perhaps an implementation note that
many implementations prefer an interactive debugger.
∂14-Mar-89 1544 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 15:44:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 438041; Tue 14-Mar-89 18:42:58 EST
Date: Tue, 14 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903140019.AA02631@defun.utah.edu>
Message-ID: <19890314234118.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
This looks good so far. A few comments that might help you
along with the draft:
VARIABLE-KIND should return the same second value that FUNCTION-KIND
returns.
It's a good idea to avoid the ambiguous word "may" and say "might",
"must", or "is permitted to".
I would assume that VARIABLE-TYPE is not required to return the
exact declared type specifier, but could return another type
specifier that is equivalent, or possibly another type specifier
that is a supertype. An implementation that canonicalizes type
declarations would do this. For example, if A was declared
(INTEGER 0 4999), VARIABLE-TYPE might return that list, another
list that was EQUAL to it but not EQ, the list (INTEGER (-1) (5000)),
the symbol FIXNUM, or perhaps something else. Similarly OR's and
AND's might be reduced to simpler type specifiers in an implementation
dependent way. If, on the other hand, VARIABLE-TYPE is not permitted
to do this, but must return the exact type specifier used in the
declaration, that would be okay, but should be stated explicitly.
Similar comments apply to FUNCTION-FTYPE of course.
I assume AUGMENT-ENVIRONMENT is permitted to share structure with
its env argument, although the proposal says "a copy of ENV".
The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
of a MACROLET special form, instead it should be a list of lists (name
function). That is, the expander functions should be supplied in the
form of functions rather than in the form of the source text used by
MACROLET. Your rationale argues against this but I strongly believe
that the rationale is wrong. I wouldn't mind seeing the parsing portion
of MACROLET made available as a separate function.
No way is provided to retrieve declarations other than SPECIAL, TYPE,
FTYPE, and LEXICAL (if PROCLAIM-LEXICAL passes). I think all
declarations should be retrievable, but OPTIMIZE declarations seem
particularly useful to retrieve in macros or optimizers that expand into
different code depending on the safety level or the speed/space
tradeoff. The irregular structure of declarations makes retrieving
them a bit complex, but here's my suggestion:
DECLARATION decl-type name &optional env [Function]
decl-type is a symbol. The interpretation of name depends
on decl-type. If a declaration of that type and name is
in force in the specified environment, it is returned, otherwise
NIL is returned. The following decl-types are specified,
additional implementation-dependent types could be added:
INLINE function-name => T or NIL
NOTINLINE function-name => T or NIL
IGNORE variable-name => T or NIL
OPTIMIZE quality => integer
DECLARATION decl-type => T or NIL
The possible interpreter implementation of COMPILER-LET I mentioned
in another message earlier today would seem to require another
keyword argument to AUGMENT-ENVIRONMENT. Does this mean that we
have to dictate some particular interpreter implementation of
COMPILER-LET? I'm unsure.
Symbolics Genera includes an undocumented internal macro, used
quite a bit in the implementation of the interpreter and code
analyzers, that could have been called WITH-AUGMENTED-ENVIRONMENT,
taking keywords like AUGMENT-ENVIRONMENT and also body forms,
and producing an environment with dynamic extent bound to a
variable within the body forms. Would it be useful to have this
too, or instead of AUGMENT-ENVIRONMENT? I'm unsure.
On SYNTACTIC-ENVIRONMENT-ACCESS:MEDIUM, my feeling today is that
this should be left out for now, even though I think we will want
something like it later, at the same time that CLOS metaobjects
go in.
Ditto for SYNTACTIC-ENVIRONMENT-ACCESS:LARGE.
∂14-Mar-89 1555 X3J13-mailer LETTER BALLOT -- Sun Microsystems
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 15:55:09 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA21551; Tue, 14 Mar 89 15:16:32 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA11449; Tue, 14 Mar 89 15:12:40 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA26931; Tue, 14 Mar 89 15:16:13 PST
Date: Tue, 14 Mar 89 15:16:13 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903142316.AA26931@clam.sun.com>
To: chapman%aitg.DEC@decwrl.dec.com
Subject: LETTER BALLOT -- Sun Microsystems
Cc: kempf%clam@Sun.COM, peck%clam@Sun.COM, sgadol%clam@Sun.COM,
x3j13@sail.stanford.edu
This is the Sun Microsystems vote.
________________________________________________________________________
Issue or section name | Version | Y | I | A |
------------------------------------------------------------------------
CUT-OFF-DATES | 4 | | I | |
------------------------------------------------------------------------
ERROR-TERMINOLOGY | 5 | | I | |
------------------------------------------------------------------------
FONTS | 2 | Y | | |
------------------------------------------------------------------------
TOC | 1 | Y | | |
------------------------------------------------------------------------
Section 1.8 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.3 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.4 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.5 | 5.8 | | | A |
------------------------------------------------------------------------
Section 6.1 | 5.8 | | I | |
------------------------------------------------------------------------
Overall, I'm impressed with the work that has been done on
writing the standard, but not entirely comfortable with the process
I can see for getting from where we are to an actual standard.
CUT-OFF-DATES
I have both general and specific comments about the CUT-OFF-DATES
proposal. The general comments first:
The cutoff dates question causes me some discomfort, and I think
that is because the proposal is not as explicit as it might be.
First, how about stating what the goal for 12/89 is? E.g. a
draft standard approved by X3J13 and ready for release and
outside comments.
Second, as I understand it, the "final changes" dates are for
final changes from the selected reviewers for each section of
the standard, though this is not stated.
The process, as I understand it, is that a set of reviewers will
read each section (or set of tool descriptions) carefully and
submit corrections, etc.. The full committee will then vote on
these.
A proper review will need to be done by subject rather than by sections
of the alphabet. In fact at least one person at Sun has volunteered to
work on a particular subject. Note that Moon expects Symbolics
internal reviewers to do likewise. To me that implies the catalog of
tools must be voted on by subject rather than alphabetically, so I
recommend reorganizing those cutoff dates and votes by subject.
Moon suggests that it will take "several months" for Symbolics
to review the draft standard, and that the availability of
the cleanup process will be important for fixing problems
in the statement of the draft standard. I second this.
Being active in the compiler committee, I feel confident that a
well-constructed section on compilation will *not* be ready by
4/22/89. We need to bring the compiler work to a conclusion as close
to that date as we can, though, even if all is not perfect. The full
committee needs to help make this happen. (Thanks especially to David
Moon for his recent input.)
ERROR-TERMINOLOGY
The error terminology is OK, except for "consequences
are unspecified". That concept is broken, though it
has serious defenders. For example, Dick Gabriel says,
"If we were to drop this term, then every time we are
``explicitly vague'' a valid possibility is that a fatal
error can occur. How is it any better to say that what happens
when some operation happens is ``explicitly vague''."
A typical area of "explicit vagueness" is the destructive operations
on lists. The explicit vagueness here is quite limited. For
some operations any top level cell of certain lists may or may
not be modified. Similar statements apply to other operations.
The consequences are far from being unspecified but harmless.
They are CONSTRAINED but meaningful.
In other situations we may say that order of certain actions
is unspecified or we may say that a side effect may or may not
occur. (For example, numerical operations may be performed
in any of various orders.) All of these are appropriate ways
to state a specification.
Maybe someone will make me suddenly see the light and I'll realize
how silly I've been, but so far the idea of consequences being
"unspecified but harmless" seems more like a witticism than
a useable idea.
SECTION 6.1
Under "Other Information", many of the terms are actually
type specifiers. Wouldn't it be better to say that if a name
is the same as a type specifier, that argument must satisfy
the type specifier?
arguments to the function -- unclear to me
boolean -- I presume this are to be arguments where
all non-NIL values are *treated* alike.
Note that for macros we truly specify *syntax* (at least
for some, e.g. defstruct. For most functions we actually
give a lambda list.
p6-8, item 2b, the keyword :test-not has been flushed from
the sequence functions.
∂14-Mar-89 1610 X3J13-mailer Re: Issue: UNSOLICITED-MESSAGES
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:09:57 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07509; 14 Mar 89 18:01 GMT
Date: Tue, 14 Mar 89 17:58:24 GMT
Message-Id: <8289.8903141758@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: UNSOLICITED-MESSAGES
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, barmar@think.com
Cc: chapman <@decwrl.dec.com:chapman@aitg.dec>, x3j13@sail.stanford.edu
> Why is this problem unique to Lisp? Is there any wording in the C
> standard that explicitly prohibits malloc() from causing output? I
> doubt it, yet I don't think they find this disturbing.
>
> Maybe it's because C people have traditionally been willing to settle
> for less. :-) Seriously, I think it's a clear hole in their standard.
> People would probably flame if things that weren't documented as doing
> I/O were to suddenly start doing it.
As far as I know, the C standard also doesn't say that assignment
doesn't print out "I'm doing an assignment" or, indeed, that y = 6
doesn't also assign 17 to xyzzy. But does it need to make explicit
prohibitions?
The C standard says "In the abstract machine, all expressions are
evaluated as specified by the semantics." Presumably there is an
implication that it doesn't do random other things.
-- Jeff
∂14-Mar-89 1629 CL-Compiler-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:29:32 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557038; Tue 14-Mar-89 19:27:03 EST
Date: Tue, 14 Mar 89 19:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-COMPILABLE-TYPES, version 8
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131612.AA02083@defun.utah.edu>
Message-ID: <19890315002703.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I apologize in advance for the length of this message.
This is good except for a few typos and the controversial business about
functions. I'd really like to see another round of editing to clean up
these problems before we're asked to vote on this.
I suggest moving everything having to do with functions to a
separate proposal. What's currently in the body of the proposal for
functions does not make any sense to me. I basically agree with the
comments from both Loosemore and Gabriel about this quoted in the
discussion section. However, we need to be careful when we discuss this
to distinguish between a function as a constant in compiled code, and a
form whose result is a function appearing in compiled code. The former
is `(quote ,#'(lambda ...)), the latter is `#'(lambda ...). The meaning
of the latter is clear, of course, and a useful question would be
whether it can fully satisfy the need for functions in compiled code and
eliminate any demand for the former.
I've said this before, but I still think the proposal would be
easier to understand if it explicitly dealt separately with
(1) relation of objects in the input of COMPILE-FILE to corresponding
objects in the result of LOAD of the output of COMPILE-FILE.
(2) relation of two objects in the output of a single COMPILE-FILE.
(3) relation of two objects in the output of two different COMPILE-FILEs.
instead of smushing these together in a fuzzy way. Look at the discussion
of uninterned symbols, for example: I found it incomprehensible.
Typos:
For any object that
appears in a constant, but is not supported by the language as part of
a constant, the behavior of the compiler is unspecified; either the
the compiler and/or loader will handle that constant (in an
implementation-dependent manner) or the compiler will detect the
situation and signal an error.
This says that the behavior of the compiler is unspecified and then
proceeds to specify it!
Because hash keys can be aggregate objects and because we treat hash
tables as unordered sets of <key, value> pairs, similarity of hash
tables is more complex. See under "Hash Tables", below, for the
definition.
I have no idea how this paragraph got into the middle of the discussion
of uninterned symbols.
References to packages are permitted in any constant.
This sentence is redundant, or else it implies that references to some
other types are permitted in some constants but not in other constants,
which I don't think you intended.
At load time, the package becomes the same as returned by
I don't know what it means for a package to "become". I think
this is just fractured syntax, though. See again my suggestion
for distinguishing the three types of similarity, which I think
indicates how to rewrite this sentence to be clear.
Under hash table:
The table's test is unchanged also.
Unchanged from what? I think what this was supposed to say was
that the table's test is a "basic attribute."
Consider a hash table as an unordered set of key and
value pairs. Two hash tables are similar as constants
exactly if there is a one-to-one correspondence between
the key and value pairs of each and a one-to-one
correspondence between the uninterned symbols of each
such that the two keys of each corresponding pair are
similar as constants and the two values are also similar
as constants. The correspondence of uninterned symbols
must be consistent with the correspondence defined for
the entire set of constants in the file.
This paragraph is totally garbled. If you took out the
stuff about uninterned symbols it might make sense.
Structure, Standard-object
<<There is a cl-cleanup issue, LOAD-OBJECTS, pending
which proposes a mechanism for dealing with objects.>>
For structure instances with no method defined at compile
time for MAKE-LOAD-FORM, the slot values and the name of
structure type (a symbol reference) are recorded by the
compiler and reconstructed by the loader.
The text not enclosed in french quotation marks directly contradicts
the LOAD-OBJECTS proposal. It should be removed so we don't have two
proposals trying to talk about the same thing.
This sentence in the discussion section:
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
seems to be in the wrong document, since this issue is not about
coalescing of constants and does not otherwise mention it, except
incidentally in connection with a bug in Coral Lisp.
∂14-Mar-89 1636 CL-Compiler-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:36:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557048; Tue 14-Mar-89 19:34:07 EST
Date: Tue, 14 Mar 89 19:34 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-COMPILABLE-TYPES, version 8
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131612.AA02083@defun.utah.edu>
Supersedes: <19890315002703.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Fix some typos in the definitions of the three concepts that I claim
should not be smushed together. Cris Perdue pointed out these typos
earlier, but I forgot to fix them before sending the first copy of this
message.
Message-ID: <19890315003408.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I apologize in advance for the length of this message.
This is good except for a few typos and the controversial business about
functions. I'd really like to see another round of editing to clean up
these problems before we're asked to vote on this.
I suggest moving everything having to do with functions to a
separate proposal. What's currently in the body of the proposal for
functions does not make any sense to me. I basically agree with the
comments from both Loosemore and Gabriel about this quoted in the
discussion section. However, we need to be careful when we discuss this
to distinguish between a function as a constant in compiled code, and a
form whose result is a function appearing in compiled code. The former
is `(quote ,#'(lambda ...)), the latter is `#'(lambda ...). The meaning
of the latter is clear, of course, and a useful question would be
whether it can fully satisfy the need for functions in compiled code and
eliminate any demand for the former.
I've said this before, but I still think the proposal would be
easier to understand if it explicitly dealt separately with
(1) relation of objects in the input of COMPILE-FILE to corresponding
objects in the result of LOAD of the output of COMPILE-FILE.
(2) relation of two objects in the result of LOAD of the output
of a single COMPILE-FILE.
(3) relation of two objects in the result of LOAD of the output
of two different COMPILE-FILEs.
instead of smushing these together in a fuzzy way. Look at the discussion
of uninterned symbols, for example: I found it incomprehensible.
Typos:
For any object that
appears in a constant, but is not supported by the language as part of
a constant, the behavior of the compiler is unspecified; either the
the compiler and/or loader will handle that constant (in an
implementation-dependent manner) or the compiler will detect the
situation and signal an error.
This says that the behavior of the compiler is unspecified and then
proceeds to specify it!
Because hash keys can be aggregate objects and because we treat hash
tables as unordered sets of <key, value> pairs, similarity of hash
tables is more complex. See under "Hash Tables", below, for the
definition.
I have no idea how this paragraph got into the middle of the discussion
of uninterned symbols.
References to packages are permitted in any constant.
This sentence is redundant, or else it implies that references to some
other types are permitted in some constants but not in other constants,
which I don't think you intended.
At load time, the package becomes the same as returned by
I don't know what it means for a package to "become". I think
this is just fractured syntax, though. See again my suggestion
for distinguishing the three types of similarity, which I think
indicates how to rewrite this sentence to be clear.
Under hash table:
The table's test is unchanged also.
Unchanged from what? I think what this was supposed to say was
that the table's test is a "basic attribute."
Consider a hash table as an unordered set of key and
value pairs. Two hash tables are similar as constants
exactly if there is a one-to-one correspondence between
the key and value pairs of each and a one-to-one
correspondence between the uninterned symbols of each
such that the two keys of each corresponding pair are
similar as constants and the two values are also similar
as constants. The correspondence of uninterned symbols
must be consistent with the correspondence defined for
the entire set of constants in the file.
This paragraph is totally garbled. If you took out the
stuff about uninterned symbols it might make sense.
Structure, Standard-object
<<There is a cl-cleanup issue, LOAD-OBJECTS, pending
which proposes a mechanism for dealing with objects.>>
For structure instances with no method defined at compile
time for MAKE-LOAD-FORM, the slot values and the name of
structure type (a symbol reference) are recorded by the
compiler and reconstructed by the loader.
The text not enclosed in french quotation marks directly contradicts
the LOAD-OBJECTS proposal. It should be removed so we don't have two
proposals trying to talk about the same thing.
This sentence in the discussion section:
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
seems to be in the wrong document, since this issue is not about
coalescing of constants and does not otherwise mention it, except
incidentally in connection with a bug in Coral Lisp.
∂14-Mar-89 1651 CL-Compiler-mailer issue QUOTE-SEMANTICS, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:51:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557056; Tue 14-Mar-89 19:48:51 EST
Date: Tue, 14 Mar 89 19:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue QUOTE-SEMANTICS, version 2
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131721.AA02184@defun.utah.edu>
Message-ID: <19890315004852.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor QUOTE-SEMANTICS:NO-COPYING for two reasons:
(1) it's clearly more aesthetic.
(2) I can't support either of the other two proposals because they use
the words "copying" and "coalescing" without defining their meaning.
My position could be changed to
QUOTE-SEMANTICS:COPYING-ALLOWED-BUT-NO-CONSTRAINTS by adding definitions
for those two words and by a strong argument that the implementation
cost of QUOTE-SEMANTICS:NO-COPYING is too high, since I believe to some
extent JonL's argument (quoted in the discussion section) that EQL of
(some types of) constants does not matter.
I can't imagine any argument that would convince me to
support QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE. I believe Kent's
arguments against it (quoted in the discussion section).
∂14-Mar-89 1700 CL-Compiler-mailer issue MACRO-CACHING, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:00:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557059; Tue 14-Mar-89 19:57:55 EST
Date: Tue, 14 Mar 89 19:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue MACRO-CACHING, version 2
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131647.AA02151@defun.utah.edu>
Message-ID: <19890315005756.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I support MACRO-CACHING:DISALLOW. I'd like to point out that the
"correct" way to do macro caching is not mentioned anywhere in this
writeup. Perhaps that was justified because there is no portable way to
do it (an implementation can do it, but a user cannot), however I think
omitting it leaves a false impression.
The "correct" way to do macro caching is via a table inside the lexical
environment structure, which has very different properties from a table
keyed by the lexical environment structure, mentioned in the writeup.
I think a shorter writeup might be better. It could simply say that
there is no correct portable way to use *MACROEXPANSION-HOOK* to cache
macro expansions, and that there is no requirement that an implementation
call the macro expansion function more than once for a given form
and lexical environment. This prohibits the incorrect user code discussed
at some length in the existing writeup, leaves implementations license
to do macro caching correctly, and avoids a lot of unnecessary detail.
∂14-Mar-89 1704 CL-Compiler-mailer issue LOAD-TIME-EVAL, version 11
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:04:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 557069; 14 Mar 89 20:02:04 EST
Date: Tue, 14 Mar 89 20:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue LOAD-TIME-EVAL, version 11
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131631.AA02140@defun.utah.edu>
Message-ID: <19890315010205.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I like LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM.
∂14-Mar-89 1722 CL-Compiler-mailer issue CONSTANT-COLLAPSING, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:21:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557083; Tue 14-Mar-89 20:10:42 EST
Date: Tue, 14 Mar 89 20:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-COLLAPSING, version 5
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131622.AA02093@defun.utah.edu>
Message-ID: <19890315011043.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
The proposal says:
State the an implementation is permitted to coalesce constants
appearing in code to be compiled if they are equivalent under the
relationship defined in proposal CONSTANT-COMPILABLE-TYPES:SPECIFY.
I can't understand what this means. The referenced proposal uses
the word "similar", not "equivalent". I'd support this alternate
wording:
Suppose that A and B are two objects used as quoted constants in the
input to COMPILE-FILE, and that A' and B' are the corresponding
objects used as constants in the result of loading the output of
that COMPILE-FILE. If A' is similar as a constant to both A and B,
then it is valid for A' and B' to be EQL even if A and B are not EQL.
This may still be too vague, since "objects in the input to
COMPILE-FILE" means not in the input text file, which doesn't contain
objects, but in the result of applying READ to the input file, and since
"corresponding objects" is not defined.
∂14-Mar-89 1722 CL-Compiler-mailer issue CONSTANT-CIRCULAR-COMPILATION, version 7
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:21:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557096; Tue 14-Mar-89 20:15:39 EST
Date: Tue, 14 Mar 89 20:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 7
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131619.AA02090@defun.utah.edu>
Message-ID: <19890315011539.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor CONSTANT-CIRCULAR-COMPILATION:YES except that all references to
EQ should be changed to EQL. There is no reason to require
implementations to be careful about EQ of numbers and characters.
∂14-Mar-89 1731 X3J13-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:31:12 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 14:57:16 PST
Date: 14 Mar 89 14:56 PST
From: masinter.pa@Xerox.COM
Subject: Issue: GENSYM-NAME-STICKINESS (Version 1)
To: x3j13@SAIL.Stanford.EDU
reply-to: cl-cleanup@sail.stanford.edu
line-fold: no
Message-ID: <890314-145716-2049@Xerox>
Additional Comments include:
"... it's ... late to consider things like this ..."
"YAY!!! This is what "cleanup" is for. Go For It! "
"Sounds like a good idea to me."
!
Issue: GENSYM-NAME-STICKINESS
Forum: Cleanup
References: GENSYM (p169)
Category: CHANGE
Edit history: 14-Feb-89, Version 1 by Pitman
Problem Description:
Many people avoid use of the argument to GENSYM because the argument
is `sticky' and such stickiness can lead to confusion. The problem is
that if any application (usually a macro) uses the gensym argument at
all, then all applications are forced to. If they do not, they risk
finding that the `helpful' argument supplied in some previous call will
be harmful to them.
Proposal (GENSYM-NAME-STICKINESS:WASH-HANDS):
Define that if an optional argument is given to GENSYM, it does NOT
have a side-effect on GENSYM's internal state.
Rationale:
Conscientious programmers are forced now to write their own GENSYM
lookalikes because they know the system's GENSYM has an invasive
effect. This defeats the primary intended function of GENSYM, which
is to satisfy the most common idiomatic use of MAKE-SYMBOL.
The stickiness of the GENSYM prefix was an attempt to be gratuitously
compatible with Maclisp, at the expense of good programming pratice.
Users who need the old behavior of GENSYM can trivially implement
that behavior using MAKE-SYMBOL.
Test Case:
(CHAR-EQUAL (CHAR (SYMBOL-NAME (SECOND (LIST (GENSYM "A") (GENSYM)))) 0)
#\G)
=> NIL ;under CLtL
=> T ;under this proposal
Current Practice:
Symbolics Cloe and Genera are compatible with CLtL, so this would be an
incompatible change.
Cost to Implementors:
Very small.
Cost to Users:
Most uses of GENSYM do not depend on the stickiness of the name, so the
change would be compatible. In some cases, the change would be an
improvement. Even in the worst case where someone depends on stickiness,
it's extremely straightforward to write the couple of lines of code to
produce an application based on MAKE-SYMBOL that is at least as flexible
as GENSYM, and often moreso.
Cost of Non-Adoption:
Good programmers would avoid using the argument to GENSYM (or using
GENSYM altogether) in many situations where they ought not have to.
Benefits:
Gensyms which appear to convey information through their name would not
accidentally pop out and cause confusion in places where they oughtn't.
Aesthetics:
Unnecessary global state changes are hard to reason about. This would
be a small simplification.
Discussion:
Pitman claims to have written a non-sticky GENSYM function for nearly
every one of the dozen or so large systems that he's written or worked
on in the last decade in order to get around the stated problem.
Others have suggested similar experience.
Pitman supports the proposal.
----- End Forwarded Messages -----
∂14-Mar-89 1730 CL-Compiler-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:29:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 557112; 14 Mar 89 20:27:21 EST
Date: Tue, 14 Mar 89 20:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131544.AA02070@defun.utah.edu>
Message-ID: <19890315012722.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I much prefer the option FLUSH, which was in version 2 but has been
removed. That option was to remove the COMPILED-FUNCTION type.
This type has no portable meaning and never should have existed.
I have no objection to the proposed specification of what the COMPILE
and COMPILE-FILE functions do, but it should be decoupled from the
COMPILED-FUNCTION type and discussed under the rubric of those two
functions. The parts about COMPILER-LET and EVAL-WHEN can probably be
removed (assuming the COMPILER-LET-CONFUSION proposal that eliminates
the possibility of COMPILER-LET binding any variables at run time
passes, and the EVAL-WHEN-NON-TOP-LEVEL proposal passes) since they are
redundant; there is never any interpeter/compiler difference for
COMPILER-LET or EVAL-WHEN any more.
∂14-Mar-89 1731 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:31:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 14:29:58 PST
Date: 14 Mar 89 14:24 PST
From: masinter.pa@Xerox.COM
Subject: Issue: COERCE-INCOMPLETE (Version 3)
To: X3J13@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
line-fold: no
Message-ID: <890314-142958-1976@Xerox>
There are a couple of "additional comments" on the proposal
at the end.
!
Issue: COERCE-INCOMPLETE
Reference: COERCE (p50)
Category: ADDITION/CHANGE
Edit history: Version 1 of COERCE-INCOMPLETE, 26-Feb-88 by M. Ida
Version 1 of COERCE-FROM-TYPE, 20-Jun-88 by Pitman
Version 2 of COERCE-INCOMPLETE, 21-Nov-88 by Pitman
(consolidate previous two proposals)
Version 3 of COERCE-INCOMPLETE, 07-Mar-89 by Pitman
(eliminate unpopular proposal, two new options)
Problem Description:
COERCE is difficult to extend because ambiguities arise about the
source type of the coercion.
For example, if the symbol STRING were permitted as a second argument
to coerce, as in (COERCE NIL 'STRING), there would be two posssible
return values: "" or "NIL". The choice would be arbitrary and would
have to be specified by the documentation. No matter which was chosen,
it would probably turn out to be a problem for some applications at
some times.
Another example is (COERCE (CHAR-CODE #\A) 'STRING). This might
return the same as (FORMAT NIL "~D" (CHAR-CODE #\A)) -- "65" in
most ASCII-based implementations -- or it might return "A". Again,
the choice would be arbitrary.
There is clear desire on the part of the user community to lift some of
the existing restrictions on arguments to COERCE, but because of legitimate
concerns about ambiguities, the Common Lisp designers have thus far
refused to do so.
Unfortunately, the failure of COERCE to handle these cases means it is
very difficult to learn to use COERCE. And the fact that COERCE is not
easily learned contributes to difficulty in learning Common Lisp because
instead of a single coercion operator with general purpose semantics, a
number of very special purpose coercion operators must be learned instead.
Some middle ground needs to be found, which neither compromises the
clear semantics and portable nature of COERCE nor complicates COERCE
in a way that makes it unlearnable.
Also, some people have expressed a desire for COERCE to be more
`symmetric.' Usually they seem to mean that they want it to be the case
that if (COERCE x y) works, then (COERCE (COERCE x y) (TYPE-OF x))
should also work. Although this is not an essential desire, it would
certainly be nice to achieve.
Proposal (COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION):
Define COERCE to accept the following equivalences:
1. (COERCE x 'STRING) == (STRING x)
2. (COERCE x 'PATHNAME) == (PATHNAME x)
3. (COERCE x 'RATIONAL) == (RATIONAL x)
Clarify that
4. (COERCE x 'FLOAT) == (FLOAT x)
Rationale:
Many users think of STRING, for example, as ``the way to coerce
something to a string'' and are baffled why COERCE and STRING
disagree on how to do this.
Such users think that if there's a moral battle to be waged
over how to coerce an object to a STRING, the battle has already
been lost by defining the STRING function -- that whatever
decision is made for STRING must also apply to COERCE for the
sake of simplicity.
Similar arguments can be made for PATHNAME, FLOAT, and RATIONAL.
Proposal (COERCE-INCOMPLETE:DEPRECATE):
Deprecate COERCE.
Rationale:
COERCE is not functionally necessary -- no operation that it does
cannot be done in some other way. As such, it is basically just
a matter of syntactic convenience, and perhaps isn't worth having
around if it will be the subject of endless debate. Deprecating
it would allow us to declare this issue a `dead end' and focus our
attention on matters of greater substance.
Current Practice:
Presumably No one implements either of the proposals at this time,
since none are compatible with CLtL.
Cost to Implementors:
COERCE: Small to moderate.
DEPRECATE: None.
Cost to Users:
COERCE: This is an incompatible change. (COERCE 'NIL 'STRING) => ""
but (STRING NIL) => "NIL". How many applications are impacted by
this change is not clear. It would be straightforward to shadow
COERCE with an alternate definition that did the old thing in
cases where people were worried. Once such cases have been
identified, rewriting
(COERCE X 'STRING)
as
(IF X (COERCE X 'STRING) "")
will suffice in most cases.
DEPRECATE: No immediate work would be needed, although many maintained
applications would get upgraded in order to use the primitives that
are `in vogue.'
Cost of Non-Adoption:
People will continue to see and debate the issues alluded to in
the Problem Description.
Benefits:
The cost of Non-Adoption will be avoided.
Aesthetics:
COERCE: Many people will probably see the idea of making
COERCE consistent with STRING, PATHNAME, FLOAT, and
RATIONAL as a clear improvement -- possibly outweighing
the costs of both an incompatible change and a decision
to arbitrarily favor one treatment over the other.
DEPRECATE: Some may take the deprecation of COERCE as an
aesthetic improvement because it eliminates the need to
debate this issue further. Others may see the
``de-centralization'' of coercion as a step backward.
Discussion:
Pitman supports COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION.
Hopefully Moon and Masinter support it, too, since it's
basically patterned after a bunch of mail they were sending
back and forth.
A proposal to extend COERCE to permit a ``view type'' argument
was considered and rejected as too extreme to consider seriously
in the timeframe available.
Pierson suggests that COERCE ought to be a candidate for
generic function status.
Pitman thinks that making [two-argument] COERCE generic would
be a -very- bad idea but believes that his earlier proposal
involving a third `view type' argument might be able to
accomodate such extension.
!
Additional comments
I agree that this is ready to send out. The thing about
COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION that strikes fear
into my heart is that it wipes out CLtL's simple statement that
any sequence type may be converted to any other sequence type,
and starts people asking questions like does
(coerce nil '(vector character)) => "" or "NIL"?
This concern is not reflected at all in the writeup.
I agree that this is ready to send out but I'm inclined to vote
no on both proposals and keep the (unsatisfactory) status quo.
----- -----
I believe that any change to the status quo is incomplete without
providing a coercion mechanism whose "viewpoint" is that of a sequence.
That is effectively what the current COERCE is, overloaded with those
types which do not conflict with SEQUENCE.
Because of the problem of differing viewpoints, I'm inclined to think
that COERCE should be shrunk down to only being a sequence coercion
function, and all other coercions should be handled by the appropriate
functions.
----- -----
∂15-Mar-89 0520 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 05:19:57 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 89 05:14:05 PST
Date: 15 Mar 89 05:13 PST
From: masinter.pa@Xerox.COM
to: X3J13@Sail.stanford.edu
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890315-051405-3472@Xerox>
At the January '89 meeting, Version 4 of this issue was amended,
and then accepted.
We think there were some wording problems with the amendment,
in that it ended up not saying what we think was intended.
The amendment made some meaningful programs have undefined
behavior, and left the meaning of SIMPLE-ARRAY unclear.
After a good deal of work by the members of the cleanup committee,
we've arrived at the following version, which we would like
to submit to you for consideration as to whether it more
properly reflects the intent of the group.
!
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289), simple arrays (p28, 289)
Category: CLARIFICATION
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
16-Jan-89, Version 5, by Gabriel. Amended at the meeting to shorten.
23-Jan-89, Version 6, by Moon. Shorten without the bug introduced
by the amendment, add clarification of SIMPLE-ARRAY type.
15-Feb-89, Version 7, by Pitman. Minor changes per comments from
RPG and Dalton.
11-Mar-89, Version 8, by Pitman. Change category, add endorsements.
Problem Description:
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288
says that ``the argument, if specified and not NIL, indicates that
it must be possible to alter the array's size dynamically after
it is created. This argument defaults to NIL.''
The description of the :ADJUSTABLE option does not say what
MAKE-ARRAY will do if the argument is unsupplied or explicitly NIL.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is
true ``if the argument (which must be an array) is adjustable, and
otherwise false.'' However, the description of MAKE-ARRAY makes
it clear that this is not necessarily the same as asking if
the array was created with :ADJUSTABLE T. If ADJUSTABLE-ARRAY-P
returns NIL, you know that :ADJUSTABLE NIL was supplied (or no
:ADJUSTABLE option was supplied), but if ADJUSTABLE-ARRAY-P returns
T, then there is no information about whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is
``not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option.'' This is inconsistent with
ADJUSTABLE-ARRAY-P.
A problem which comes up in practice is that some programmers
expect runtime error checking if they have done
(MAKE-ARRAY ... :ADJUSTABLE NIL) and they later try to adjust
the array using ADJUST-ARRAY.
The definition of the SIMPLE-ARRAY type and its subtypes needs
clarification of its relationship to adjustability.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:CLARIFY):
1. ADJUSTABLE-ARRAY-P is true of all arrays created with a true
:ADJUSTABLE option to MAKE-ARRAY. Whether ADJUSTABLE-ARRAY-P is
true of some other arrays is unspecified.
2. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER,
and :DISPLACED-TO arguments each either unspecified or false, the
resulting array is a simple array. (This just repeats what CLtL
says on page 289, it's here to aid in understanding the next point.)
3. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
:FILL-POINTER, or :DISPLACED-TO arguments true, whether the
resulting array is simple is unspecified.
4. ADJUST-ARRAY ``should signal'' an error if ADJUSTABLE-ARRAY-P
of its first argument is false. ADJUST-ARRAY must not signal an
`array not adjustable' error if ADJUSTABLE-ARRAY-P of its first
argument is true.
5. The value of ADJUSTABLE-ARRAY-P on a simple array is unspecified.
Note: ``should signal'' is taken from the new error terminology.
It means that in ``safe code'' (code compiled with highest safety)
an error must be signalled, but that in unsafe code (code not compiled
with highest safety), an error might or might not be signalled.
Clarifications and Logical Consequences:
a. Whether an array can be both simple and adjustable is unspecified.
b. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
c. There is no specified way to create an array that is non-simple.
d. This legitimizes ADJUSTABLE-ARRAY-P as an appropriate predicate to
determine whether ADJUST-ARRAY will reliably succeed.
e. If ADJUST-ARRAY is invoked on an array that was created without
supplying :ADJUSTABLE true, an `array not adjustable' error
``should be signalled'' unless ADJUSTABLE-ARRAY-P returns true on
that array (in which case it must not signal an `array not adjustable'
error).
Rationale:
This effectively makes the status quo explicit. This preserves the
raison d'etre of simple arrays, which is to provide a portable interface
to implementation-dependent specialized arrays that trade decreased
functionality for faster access.
Specifying the points left unspecified (requiring all simple arrays to be
non-adjustable and all adjustable arrays to be non-simple) would require
large changes to some implementations and would be of little benefit to
users, merely making one kind of nonconforming program fail in all
implementations instead of failing only in some implementations. The
argument here is not that the error checking would not be useful for
developers of portable code, but only that the cost of introducing that
error checking would be exceedingly high for some implementations.
Users need to know that certain arrays are simple, so they can put in
declarations and get higher performance, but users have no need to be
able to create arrays that are definitely non-simple (for lower
performance) or definitely non-adjustable (to cause errors).
Examples:
1. The following program is conforming. It is unspecified which branch
of the IF it follows.
(defun double (a)
(if (adjustable-array-p a)
(adjust-array a (* (length a) 2))
(let ((new (make-array (* (length a) 2))))
(replace new a :end1 (length a))
new)))
(double (make-array 30))
2. The following program is conforming. In no implementation is the
type declaration violated.
(let ((a (make-array 100)))
(declare (simple-array a))
(frob a))
Current Practice:
Probably everyone is compatible with this proposal.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and ignores adjustability in deciding whether an array is simple,
and is compatible with this proposal.
Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL arrays non-adjustable
in all cases, and make all arrays non-simple unless the Common Lisp
language requires them to be simple, and are compatible with this proposal.
Cost to Implementors:
It's in principle possible that some implementation would have to change,
but in practice there are no known implementations that would have to change.
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Benefits:
Users would know what to expect.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired error checking.
Aesthetics:
Most people believe the status quo is unaesthetic. Having an aspect of
the language explicitly unspecified is more aesthetic than having it
implicitly unspecified on account of vague or inconsistent documentation.
Discussion:
Pitman, Moon, Gabriel, and Steele support this amended proposal.
MACSYMA ran into portability problems due to the status quo.
If the issue had been documented, that would have helped.
Encouraging implementations that are able to at least make
(MAKE-ARRAY ... :ADJUSTABLE NIL) create non-adjustable arrays
where possible would help, too.
We considered proposals to incompatibly change this primitive in a
variety of ways, but the community was very split with strong proponents
and opponents of each alternate proposal.
The overriding concern driving this proposal is that Symbolics
has asserted that most of the other really interesting proposals would
likely involve a sizable cost to implementors (and their installed bases)
to implement what were judged by some as gratuitous changes from the
status quo.
Pitman wishes some of the other proposals were economically feasible to
pursue but reluctantly agrees that maintaining (and clearly documenting)
the status quo is probably the most reasonable avenue left to us.
∂15-Mar-89 0622 X3J13-mailer BASE-CHARACTER
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 06:22:19 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 06:09:24 PST
Date: 15 Mar 89 06:07 PST
From: masinter.pa@Xerox.COM
Subject: BASE-CHARACTER
To: CL-Characters@SAIL.STANFORD.EDU
cc: X3J13@SAIL.STANFORD.EDU
Message-ID: <890315-060924-3563@Xerox>
There were a couple of points that were only tersly alluded to in my note
on the character proposal.
BASE-CHARACTER
I think most of the confusions and problems with BASE-CHARACTER in the
proposal result from its definition in terms of the 'natural' encoding of
an implementation.
I think defining BASE-CHARACTER exactly as
(UPGRADED-ARRAY-ELEMENT-TYPE 'STANDARD-CHAR)
has all of the right properties. (Recall that UPGRADED-ARRAY-ELEMENT-TYPE
was added by the (passed) proposal in ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS.)
This definition is unambiguous and shows the relationship between the
string encoding and array upgrading strategies of the implementation and
the important character types. It ensures STANDARD-CHAR is a subtype of
BASE-CHARACTER.
Whether a character is "base" really only depends on the way that an
implementation represents strings, and not any other properties of the
implementation or the host operating system. Imagine two implementations on
a Unix machine, one of which encodes all strings as 16-bit characters, and
another which has two kinds of strings: 8-bit strings and 16-bit strings.
In the first implementation, the BASE-CHARACTER is CHARACTER: there's only
one kind of string. In the second implementation, the BASE-CHARACTER would
be those that could be stored in an 8-bit string, and it would be a proper
sub-type of CHARACTER.
To make this change requires leaving STANDARD-CHAR in the standard and then
merely defining BASE-CHARACTER in terms of it. Clearly BASE-STRING, if such
a name is necessary, would then just be a shorthand for (VECTOR
BASE-CHARACTER) with all the semantics implied by the array-element-type
proposals.
∂15-Mar-89 0636 X3J13-mailer Issue IN-PACKAGE-FUNCTIONALITY (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 06:35:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 06:27:41 PST
Date: 15 Mar 89 06:27 PST
From: masinter.pa@Xerox.COM
Subject: Issue IN-PACKAGE-FUNCTIONALITY (Version 8)
To: X3J13@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890315-062741-3597@Xerox>
Version 4 of this issue (with only a version of
the SELECT-ONLY proposal) was discussed and tabled
at the last meeting.
This version includes two proposals; NEW-MACRO
(favored by many members of the cleanup committee)
and a new version of SELECT-ONLY.
!
Issue: IN-PACKAGE-FUNCTIONALITY
References: IN-PACKAGE (p182-183)
Category: CHANGE
Edit history: 07-Jul-88, Version 1 by Pitman
7-Oct-88, Version 2 by Masinter (discussion)
8-Dec-88, Version 3 by Masinter
12-Dec-88, Version 4 by Masinter
20-Jan-89, Version 5 by Loosemore
30-Jan-89, Version 6 by Loosemore
10-Mar-89, Version 7 by Loosemore
15-Mar-89, Version 8 by Masinter
(add back SELECT-ONLY)
Related-Issues: DEFPACKAGE (passed)
COMPILE-FILE-SYMBOL-HANDLING
Problem Description:
There are two typical uses for IN-PACKAGE -- to define/create a package
and to select a package. The fact that these two purposes have been
given to the same function has led to reduced error checking.
A more general problem is that the "Put In Seven Extremely Randoms"
convention described in CLtL is now recognized by many people as being
unsatisfactory for both package definition and package selection.
The DEFPACKAGE macro provides a much cleaner mechanism for package
definition, but there is still a need for a convenient way to select
a package that has well-defined compilation semantics.
Proposal (IN-PACKAGE-FUNCTIONALITY:NEW-MACRO):
Add a new macro:
SELECT-PACKAGE name [macro]
This macro causes *PACKAGE* to be set to the package named NAME,
which must be a symbol or string. An error is signalled if the
package does not already exist. Everything this macro does is also
performed at compile time if the call appears at top-level.
Remove the function IN-PACKAGE from the standard.
Remove the second paragraph of section 11.7 in CLtL. (This includes
the requirement for special compile-time treatment of the various
package functions.)
Rationale:
This could allow improved error checking and modularity, with only
minimal loss of functionality.
The rationale for proposing SELECT-PACKAGE as a replacement for
IN-PACKAGE, rather than simply changing IN-PACKAGE to have this
behavior, is that such an incompatible change would be confusing to
many people, and would make it more difficult to detect obsolete
usages. There is nothing in this proposal that would prevent
implementations from continuing to provide IN-PACKAGE as an extension.
Making SELECT-PACKAGE a macro rather than a function means that there
is no need to require COMPILE-FILE to handle it specially. Since
DEFPACKAGE is also defined to side-effect the compilation environment,
there is no need to require any of the package functions to be treated
specially by the compiler.
The language in section 11.7 of CLtL puts the burden on
implementations of ensuring that all symbols in a file which is
compiled and loaded end up in the same package that they would if the
source file were loaded interpretively. No implementation can
possibly meet this requirement because, in general, the runtime
behavior of the program cannot be predicted by the compiler.
Current Practice:
Probably no one implements this behavior exactly since it's an
incompatible change to CLtL.
Cost to Implementors:
The SELECT-PACKAGE macro can be implemented trivially by using
EVAL-WHEN in its expansion:
(defmacro select-package (name)
`(eval-when (eval compile load)
(setq *package*
(or (find-package ',name)
(error "Package ~s does not exist." ',name)))))
The changes required to COMPILE-FILE to remove the magic treatment
of the package functions are also likely to be small.
Cost to Users:
In most cases, minor syntactic changes to some files would be
necessary. Programmers that are now using the "Put In Seven
Extremely Randoms" convention will probably find it straightforward
to convert their code to do a DEFPACKAGE followed by a
SELECT-PACKAGE.
Cost of Non-Adoption:
The specification of COMPILE-FILE will be much more difficult to
understand.
The standard will require compilers to solve the halting problem.
Benefits:
Modular package declarations would be encouraged and errors due
to demand-creation of packages would be easier to detect.
The specification of COMPILE-FILE will be simplified.
There will be a clear statement of the requirements for program
conformance, as relating to usage of packages.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether
the package should exist already or not) is clearly not aesthetic.
Removing it can't be any worse.
The fact that the currently stated requirements for handling of
the package functions by the compiler are not implementable is
clearly not aesthetic.
!
Proposal (IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY):
Eliminate the ability of IN-PACKAGE to create a package on demand.
Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
are no longer needed.
The results of calling IN-PACKAGE if the package does not already
exist are implementation dependent; implementations "should signal"
an error, or otherwise provide the user with a way to recover from
the situation.
Examples:
#1: (IN-PACKAGE 'NO-SUCH-PACKAGE) ;would signal an error
#2: (DEFPACKAGE FOO ...options...) ;defines/creates a package
(IN-PACKAGE 'FOO) ;selects an existing package
Rationale:
This could allow improved error checking and modularity, with only
minimal loss of functionality.
Current Practice:
Probably no one implements this behavior since it's in direct
contradiction of both the definitions and numerous examples in CLtL.
Cost to Implementors:
As written, no change to implementations is required, but many will
want to make IN-PACKAGE signal an error. This change would be
straightforward to implement. The cost may not be trivial in all
cases, but should not be very large.
Cost to Users:
In most cases, minor syntactic changes to some files would be
necessary.
In some cases, no changes would be necessary since files may
already be doing IN-PACKAGE in situations where the author is
hoping he's made sure the real package declaration is already
loaded.
Cost of Non-Adoption:
Reduced error checking.
Less modular code.
Benefits:
Errors due to demand-creation of a package by IN-PACKAGE without
appropriate uses of the :USE or :NICKNAMES or without appropriate
calls to EXPORT, etc. afterward would be easier to detect.
Modular package declarations would be encouraged.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether
the package should exist already or not) is clearly not aesthetic.
Some people feel this change would be an aesthetic improvement.
Others feel that an incompatible change to IN-PACKAGE would merely
be confusing.
!
Discussion:
The dual use of IN-PACKAGE has not been helpful and is confusing.
Some people may find proposal NEW-MACRO more palatable if it merely
deprecated IN-PACKAGE, instead of removing it entirely.
Loosemore and Moon support proposal IN-PACKAGE-FUNCTIONALITY:NEW-MACRO.
Pitman says:
I support NEW-MACRO, though would really prefer you change "remove" to
"deprecate". Making this an incompatible change is gratuitous.